busybox support

[vanhauser-thc]

Is your feature request related to a problem? Please describe. most embedded systems are minimal installations that deploy busybox. as lynis expects standard gnu bash, ps, grep etc. this fails on all those targets.

Describe the solution you'd like support busybox installations.

Required changes detect if /bin/sh is busybox, and then switch to a different mode as bash features are mostly not supported, ps output is different (and is missing most command line parameters), grep is also missing several options that lynis is using

[agonzalez-plume]

I started working on this without realizing it. Not that far along with getting it working by going through checks one at a time to see about fixes. At least now it runs the checks, whereas when I started it was failing on special character problems it thought existed.

For OpenWRT there is a BusyBox installation, I have been making changes to my local copy of lynis to get it to work but have been using detection of OpenWRT as the Linux criteria. Maybe it should busybox instead.

[vanhauser-thc]

I think a better detection would either be readlink /bin/sh | grep -q busybox && IS_BUSYBOX=1 or sh --help 2>&1 | grep -qi busybox && IS_BUSYBOX=1 - or better both :)

[agonzalez-plume]

I see that BusyBox detection is in there. In my run, it's actually saying SHELL_IS_BUSYBOX. Just our busybox is really limited.

So far need to remove all use of advanced tr usage.

• When tr uses character sets like [:alnum:] or [:ctrl:] for example it's not good.
  • changed to [a-zA-Z0-9]
• When tr does upper to lower or lower to upper, not good
  • changed to awk '{print toupper($0)}')

I think some of my changes can go across all *nix platforms. But I am focusing on 'Linux'. I should key off the $SHELL_IS_BUSYBOX though

[alangonzalez]

Posted my current code to lynis fork on my personal github alangonzalez/lynis

It's working pretty good now, but going through tests one by one. Currently at the name services test and working through as I can. I use the testing.prf as my profile. It's got some plugins not enabled.

tests that have some level of verification - with modifications. The others are running, just not clear on if it's truthful.

• Initialization
• Os detection
• System tools
• Boot and services
• Kernel
• Memory and Processes
• User, Groups, and Auth
• Shells
• File Systems
• USB Devices
• Storage - maybe
• SSH - sorta (didn't check SSHD, added dropbear)

This version should run without obvious errors, behind the scenes it's a lot of line by line validation it's checking correctly. So I wouldn't use for report outs yet!

I'm trying to make the changes so the PR goes smoothly, but I will say I will have to go back through again and tidy up some of the fixes to insure the merge is clean and doesn't have unintended side-effects.

[mboelen]

Hi @alangonzalez - Thanks for your work in this area, much appreciated!

To prevent that we receive one big pull request later on (which is really hard to review and with the risk of introducing conflicts), can you split your changes up in small pull requests? In the upcoming days/week we will be reviewing, merging, and releasing a new version.

[agonzalez-plume]

@mboelen sure. Would this be too much for one commit?

lynis, osdetection, binaries,functions?

Could break it up more too.

After that I can do single tests or something.

[mboelen]

Normally it is better to break it up per file, so that the chance of conflicts is minimal. Feel free to submit and we review along the way. Thanks!