Created attachment 313644 [details] setup-2.7.1-sbinsanity.patch The attached patch should add /sbin:/usr/sbin:/usr/local/sbin to the end of PATH for all non-root users. The separation between **/bin and **/sbin provides no actual value and confuses everyone using Fedora. The reasoning is described more fully in the Feature page: http://fedoraproject.org/wiki/Features/SbinSanity
Created attachment 313649 [details] setup-2.7.1-sbinsanity.patch ( Well, the previous patch didn't do *quite* what I wanted; I got the order of the pathmunge() calls wrong. This new patch fixes that. Ignoring the /usr/kerberos difference (which will require changes to krb5-workstation), the situation is now this for bash: root has: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin non-root: /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin csh puts the paths in a different order, for some reason. In csh.login it has: root has: /sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin non-root: /bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin I'm not sure if it's worth changing csh to match bash behavior while we're at it, but I've ensured that the /sbin paths follow the /bin ones. I actually haven't tested the csh changes because (AFAICT) you can't actually log in if your shell is tcsh. Amazing.
Isn't it safer to put the sbins before the bins? And is it safer to put the sbins before the local-sbins?
I've never heard a valid argument for any arrangement being any "safer" than any other. And putting /sbin first would break consolehelper, as prominently mentioned in the feature page. In short: definitely no.
> I've never heard a valid argument > In short: definitely no. You seem sure for someone who doesn't know what the argument is. The argument is similar to the argument for not putting "." in the path - you put the safest things in the path first. Root's binaries should be at the beginning since root controls them. Only a comment.
Unsafe paths are paths that include user-writable directories where an attacker could place poisoned binaries. "." is a relative path and could therefore refer to user-writeable directories - e.g. /tmp. /sbin is not user-writable, nor is it relative. So that "unsafe" argument doesn't apply.
> /sbin is not user-writable, nor is it relative. True, but /usr/local/bin sometimes is, and so should not come before /sbin.
(In reply to comment #6) > > /sbin is not user-writable, nor is it relative. > > True, but /usr/local/bin sometimes is, and so should not come before /sbin. If the administrator makes /usr/local/*bin user-writable, they've decided to break their own security. The filesystem package lays them down 755, root.root. And the whole point of /usr/local is that it overrides the system search path. It _has_ to go first. The attack vectors for user-writable /usr/local are: - User adds a binary to it that is suid to themselves, which they could always do anyway. - User adds a binary there in the hopes that root runs it, in which case root already made the choice to trust that user by giving them write access to their path in the first place. So yes, if you go out of your way to give your users the ability to root you, you can be rooted. Don't Do That.
Feature page is here: https://fedoraproject.org/wiki/Features/SbinSanity
Will be taking care of it tomorrow. Thanks, Read ya, Phil
Sorry, took a few days longer, but package is building at the moment. Thanks, Read ya, Phil
(In reply to comment #7) > - User adds a binary to it that is suid to themselves, which they could always > do anyway. This is slightly ambiguous. The user always has the ability to add a binary that is suid to themself _somewhere_, not necessarily. Whether or not it behaves as such when run is a function of mount options, of course. But even in the classic unix model, the user is quite capable of giving away access to their own account.
Package has landed in rawhide. None of my testing has uncovered anything weird. Closing. Thanks!
*** Bug 143824 has been marked as a duplicate of this bug. ***