Bug 458176 - SbinSanity - add /sbin:/usr/sbin:/usr/local/sbin to end of PATH for non-root users
SbinSanity - add /sbin:/usr/sbin:/usr/local/sbin to end of PATH for non-root ...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Fedora Extras Quality Assurance
http://fedoraproject.org/wiki/Feature...
: FutureFeature
: 143824 (view as bug list)
Depends On:
Blocks: F10Blocker/F10FinalBlocker F10Beta/F10BetaBlocker
  Show dependency treegraph
 
Reported: 2008-08-06 17:07 EDT by Will Woods
Modified: 2015-03-04 20:20 EST (History)
6 users (show)

See Also:
Fixed In Version: setup-2.7.3-1
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-17 11:28:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
setup-2.7.1-sbinsanity.patch (948 bytes, patch)
2008-08-06 17:07 EDT, Will Woods
no flags Details | Diff
setup-2.7.1-sbinsanity.patch ( (948 bytes, patch)
2008-08-06 18:19 EDT, Will Woods
no flags Details | Diff

  None (edit)
Description Will Woods 2008-08-06 17:07:54 EDT
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
Comment 1 Will Woods 2008-08-06 18:19:01 EDT
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.
Comment 2 Need Real Name 2008-08-20 04:36:18 EDT
Isn't it safer to put the sbins before the bins?
And is it safer to put the sbins before the local-sbins?
Comment 3 Will Woods 2008-08-20 11:07:06 EDT
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.
Comment 4 Need Real Name 2008-08-20 11:45:06 EDT
> 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.
Comment 5 Will Woods 2008-08-20 11:57:04 EDT
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.
Comment 6 Need Real Name 2008-08-20 12:02:01 EDT
> /sbin is not user-writable, nor is it relative.

True, but /usr/local/bin sometimes is, and so should not come before /sbin.
Comment 7 Adam Jackson 2008-08-27 14:31:40 EDT
(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.
Comment 8 John Poelstra 2008-08-28 11:34:30 EDT
Feature page is here: https://fedoraproject.org/wiki/Features/SbinSanity
Comment 9 Phil Knirsch 2008-08-28 11:50:17 EDT
Will be taking care of it tomorrow.

Thanks,

Read ya, Phil
Comment 10 Phil Knirsch 2008-09-03 12:41:36 EDT
Sorry, took a few days longer, but package is building at the moment.

Thanks,

Read ya, Phil
Comment 11 Adam Jackson 2008-09-08 19:00:04 EDT
(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.
Comment 12 Will Woods 2008-09-17 11:28:26 EDT
Package has landed in rawhide. None of my testing has uncovered anything weird.

Closing. Thanks!
Comment 13 Bill Nottingham 2008-09-23 13:46:11 EDT
*** Bug 143824 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.