Bug 458176
Summary: | SbinSanity - add /sbin:/usr/sbin:/usr/local/sbin to end of PATH for non-root users | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Will Woods <wwoods> | ||||||
Component: | setup | Assignee: | Phil Knirsch <pknirsch> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | ajax, beland, dcantrell, pjones, poelstra, rvokal | ||||||
Target Milestone: | --- | Keywords: | FutureFeature | ||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
URL: | http://fedoraproject.org/wiki/Features/SbinSanity | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | setup-2.7.3-1 | Doc Type: | Enhancement | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2008-09-17 15:28:26 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 438943, 446447 | ||||||||
Attachments: |
|
Description
Will Woods
2008-08-06 21:07:54 UTC
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. *** |