0

I wonder how design permissions in root file system should look for embedded device, with busybox onboard (buildroot environment). Several ordinary users may login to the system using ssh.

My initial concept is to remove all permissions, except x, of group (root group will be accessible by admin) and others for /etc, /usr folders, /root (in this case even x will not be set). /bin folder would be set to 755, however I'm affraid of busybox binary, since it has set-uid bit turned on.

After blocking all these resources I think of explicit setting ACL-s for particular files.

For now my open points is:

  • Which system resources should be accessible by ordinary users - i'm pretty sure about the /bin folder. But what about other folders like /usr, /var etc.
  • What should I consider regarding /bin/sh -> (-rwsr-xr-x) /bin/busybox backdoor. How to block ability of running (set-uid) shell by ordinary user (I'm not sure but probably effective uid is abandoned inside busybox)
  • What about /lib folder, should I explicitly define ACL for libraries used by ordinary users? Or there is simpler solution.
  • Should I limit permissions for sysfs and procfs, or it will break down whole system?

I will be grateful for any hints.

  • 2
    Why does your busybox have setuid set? – muru Jul 12 at 10:23
  • I'm not sure. Probably it's a workaround. I haven't tried removing it, since it is set by default on buildroot. – Nabuchodonozor Jul 12 at 10:39
  • What would you like to achieve? What do you want this admin user to be able to do? What would be the purpose of having a non-root user as a member of group 0 (root)? - you don't tend to see that on general-purpose Linux distros. What is an "ordinary user" in the context of your embedded system? Is this concept partly because you have reason to believe that running useful shellcode from a network exploit is significantly harder if there is not, e.g., an existing shell binary you can execve()? – sourcejedi Jul 12 at 14:08
  • @sourcejedi admin group will be able to manipulate users according to sudoers - that is why I would like to have safe root group (no extra privileges), since it may be accessed with usermod -aG root someone by admin. Ordinary users will be configured to show some resource files from specific locations (/home directory). Also as ordinary user I mean www-data, which is owned by http server. Yes I would like to avoid running privileged shell by attacker authenticated by ordinary user. – Nabuchodonozor Jul 12 at 14:19
  • @Nabuchodonozor sorry: I should say to please edit any clarifications into your answer. – sourcejedi Jul 12 at 14:19
1

It sounds like you already know enough to choose a permission design for /home/user1, or equivalent. You're asking about the rest of the system. There are already a few discussions here, at least on a related topic:


remove all permissions, except x, of group and others for /etc, /usr folders. But what about other folders like /usr, /var etc

Looking at the Unix DAC permissions on system directories, and making them more restrictive than the provided defaults, is not a common tactic. (With the exception of permissions on user's home directories. There is usually a configuration setting for this). The only way to answer a question as broad as -

how design permissions in root file system should look

- is that you should use the standard DAC permissions for system directories. You chould check against your favourite Linux distribution if you like. You could also look at the FHS, although that may lack a few recent updates.

Getting into buildroot specifically might make it more feasible to change them. But that does not mean you that you "should"!


I would like to have safe root group (no extra privileges), since it may be accessed with usermod -aG root someone by admin.

Not recommended. You cannot allow unrestricted useradd, because of useradd -u 0, so you need wrapper scripts or something anyway. (E.g. set sudoers to allow admin to run the wrapper script as root). Better e.g. provide a wrapper script for usermod as well, and do your protection in the script. Then you can prevent attacking other non-root "system" groups (daemon accounts) as well.

"ordinary users" (beside www-data) may login using ssh.

It looks like you're trying to run a secure multi-user Unix-like system. That's the most important part of the question.

That general problem is too broad, to ask here and get a definitive answer.

If the users are completely untrustworthy, the honest answer is that you cannot. There are various tradeoffs, strategies and tactics.

The question is really not specific to "embedded device, with busybox onboard (buildroot environment)". Except that this might narrow down which tactics are easily available to you.

Specifically, note that using buildroot is going to make it a lot more work to implement security updates, compared to standard binary distributions like Debian Linux.

Out of the possible free software distributions you could look at, I am very sceptical that buildroot is aiming for highly secured multi-user Linux systems :-). (Either multi-user network servers, used in universities and some similar environments, or multi-user PCs).

Most large organizations have similar problems with internal multi-user systems. But the simplest approach they use is to not run any one large multi-user Unix (or Windows :-) instance, that users can actually run programs on!

The common case like this is actually where you have desktop PCs that can be used by different workers ("hot-desking", or just multiple shifts). Some of the common controls here are key parts of Microsoft' business model ("Group Policy") or the wider Windows ecosystem, and some are not available as free software equivalents.

One of the most powerful controls is "application whitelisting". Providing the user with a full programming / scripting environment, like the Unix shell, is a relatively high risk. It is often not needed. (And systems can absolutely be engineered to deny access to them).

I'm afraid of busybox binary, since it has set-uid bit turned on

A few of the busybox applets are standard commands that can require setuid root to work as expected. This is designed to be secure, and officially supported.

config FEATURE_SUID
bool "Drop SUID state for most applets"
default y
help

With this option you can install the busybox binary belonging to root with the suid bit set, enabling some applets to perform root-level operations even when run by ordinary users (for example, mounting of user mounts in fstab needs this).

With this option enabled, busybox drops privileges for applets that don't need root access, before entering their main() function.

If you are really paranoid and don't want even initial busybox code to run under root for every applet, build two busybox binaries with different applets in them (and the appropriate symlinks pointing to each binary), and only set the suid bit on the one that needs it.

Some applets which require root rights (need suid bit on the binary or to be run by root) and will refuse to execute otherwise: crontab, login, passwd, su, vlock, wall.

The applets which will use root rights if they have them (via suid bit, or because run by root), but would try to work without root right nevertheless: findfs, ping[6], traceroute[6], mount.

Note that if you DO NOT select this option, but DO make busybox suid root, ALL applets will run under root, which is a huge security hole (think "cp /some/file /etc/passwd").

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.