more than high-maintenance, I think [LWN.net]

more than high-maintenance, I think

Posted Nov 23, 2010 20:22 UTC (Tue) by sbishop (guest, #33061)
Parent article: Ghosts of Unix past, part 4: High-maintenance designs

I think that there is another issue with setuid that isn't mentioned in the article. I have understood it to be the reason filesystem binds (as referenced in part 2) are a privileged operation. Otherwise, you could have setuid binaries dynamically linking against a library of your own choosing, for instance.

(Log in to post comments)

more than high-maintenance, I think

Posted Nov 24, 2010 0:56 UTC (Wed) by neilbrown (subscriber, #359) [Link]

If you are thinking of filesystem binding which is system-wide - imposed on all processes, then I agree this is orthogonal to SUID/SGID.
However if you are talking about per-session filesystem binding (with process-local name spaces that are inherited across fork/exec, but not imposed on other processes), then I think this is exactly related to SUID/SGID.
A problem with SUID/SGID is that so much is inherited from the parent. The process-local name space would be inherited too, so it could affect the behaviour of the program in unexpected way.

This is "simply" avoided by allowing process-local filesystem binding, but only on to objects to which the user already has write access. However I don't know if it would be as useful with that restriction ... maybe it would.

more than high-maintenance, I think

Posted Nov 24, 2010 8:14 UTC (Wed) by nix (subscriber, #2304) [Link]

An alternative 'simple' avoidance (more of a hack, perhaps) would be to switch to a specific binding (perhaps some daemon could have the job of handing out fd's to legitimate mounts of such directories; perhaps a specific binding of the whole hierarchy, or a specific binding of particular often-security-important directories) whenever the current binary detects that it is setuid. (Obviously, its children would inherit this as usual.)

If you consider /etc, /lib, /bin, /etc /sbin, /usr/lib, /usr/bin, /usr/sbin and /usr/libexec 'security-important', then bingo, all the 'read an /etc/passwd of your own design' or 'force a setuid binary to run a new binary of your own design' attacks become impossible.

Downsides: an arms race for 'security-important directories' much as there currently is for security-important environment variables. If you rebind the whole tree then people might find that setuid apps could no longer operate on stuff in the user's own hierarchy (as soon as non-superuser mount() becomes possible), which would be seriously counterintuitive. Depends on a new daemon, but perhaps that could be the same one that does service invocation, so the same thing could provide a means of secure setuid app invocation *and* make old setuid apps more secure in the presence of user-defined mounts as well.

Perhaps what you want the 'privileged mount daemon' to do is to hand out new mounts to all filesystems not marked as 'user' in *its* /etc/fstab: that way there would be no arms race for 'security-important directories' and it would be impossible for a user to fake it out by rebinding the /etc/fstab.

This could easily be done by ld.so (except that getting this change past Ulrich is probably impossible: it feels overdesigned and fragile even to me).