Why should bin not own a directory
Brad Powell
:Hi all,
:
:I'm reading the sendmail install document and noticed a comment. It
:says the user bin should not own /bin /usr/bin and so on. Why is this
:a problem and should all the executable files owned by bin (and uucp)
:be changed to root ownership as well?
:
:Confused,
:
:Gene.
One thing I haven't seen mentioned :-)
All points about "bin" not being watched as closly as "root"
are valid, and reason enough to not do it, however _Networks_ should be mentioned
as a potential problem with "bin" owned files.
In NFS for example "root" is mapped to "nobody"
(and for a very good reason too).
"bin" is mapped to "bin" "sys" is mapped to "sys" ect....
so as a really simple example; say you export your "/usr" filesystem
read-write (default).
an intruder could, upon gaining root somewhere where he can get to your
subnet, NFS mount your "/usr" filesystem; su to "bin" on the the compromised
machine (he is root already) and then manipulate *your* /usr/bin binaries.
(trojan login?)
The obvious simple attack is just to create a .rhosts entry in *your*
/usr/bin/ (vi /mounted-dir/bin/.rhosts)
add a "+ +" entry, then login to your system as user "bin".
On some early version of SunOS /etc was owned by "bin"; thus the intruder
could then become root by playing with your /etc/passwd file.
These are fixed with a patch 100103-1X
^
not sure what the latest version number is now-a-days (15?)
I've been out of the patch business for a while
This is a simple example but gets the point across. There are literally
dozens of variations/tricks I've seen/documented on this attack.
It doesn't stop with NFS either. RPC and most of the other network functions
use unix_auth or some other network uid mapping,
Moral of the story is that "bin" should never own directories where system
files are kept, and root should never execute files from a directory that
"root" doesn't own.
=======================================================================
Brad Powell : brad....@Sun.COM |
|
Full Time: Sr. Network Security Analyst |Part time: Cyberspace PI
ENS Network Security Group | and Consultant
Sun Microsystems Inc. |
=======================================================================
The views expressed are those of the author and may
not reflect the views of Sun Microsystems Inc.
=======================================================================
Paul V. Alukal
>In article q...@geraldo.cc.utexas.edu, ge...@shallot.ots.utexas.edu writes:
>:Hi all,
>:
>On some early version of SunOS /etc was owned by "bin"; thus the intruder
>could then become root by playing with your /etc/passwd file.
I think SunOS 4.1.3 is also like this, bin owns /etc !!! Few months
back, a patch came out which fixed these permission problems.
>These are fixed with a patch 100103-1X
> ^
> not sure what the latest version number is now-a-days (15?)
> I've been out of the patch business for a while
>Moral of the story is that "bin" should never own directories where system
>files are kept, and root should never execute files from a directory that
>"root" doesn't own.
Also, better to put /bin/false as the login shell for bin in /etc/passwd.
--------------------------------------------------------------------------
Paul V. Alukal pal...@bluerose.gmi.edu
GMI Eng. & Mgmt. Institute, Computer Center
1700 West Third Avenue, Flint, MI 48504
--------------------------------------------------------------------------
ge...@shallot.ots.utexas.edu
John Messenger
In article <palukal.779057144@bluerose> pal...@bluerose.gmi.edu (Paul V. Alukal) writes:
Paul> bpo...@Sun.COM (Brad Powell) writes:
Brad> On some early version of SunOS /etc was owned by "bin"; thus
Brad> the intruder could then become root by playing with your
Brad> /etc/passwd file.
Paul> I think SunOS 4.1.3 is also like this, bin owns /etc !!! Few
Paul> months back, a patch came out which fixed these permission
Paul> problems.
This seems to be how SunOS 4.1.3_U1 is deliviered as well. Let's hope
(a) that Sun decides to issue Solaris 1.1.2 (which I've been told by
Sun is quite possible), and
(b) that they fix the directory ownership stuff, and "+" in
/etc/hosts.equiv, and so many more things.
--
-- John Messenger, Proteon International (j...@proteon.com)
Zygo Blaxell
Protection for the 'bin' user is often weaker than protection for
'root'. sendmail, for instance, checks to make sure that its effective
UID is non-root before performing dangerous operations. It doesn't (and
really can't be expected to) check to see if it is any other user (such
as one who owns many frequently executed binaries).
That said, some sites need to have a non-root user own many binaries.
This is especially true if the administration of a machine is split
into an 'applications maintainer' and 'system administrator'--the
former is responsible only for providing user software while the
latter is responsible for security, keeping the machine running, etc.
My own system has basic system binaries owned by root in 'bin' and
'usr/bin', and applications software packages owned by a non-root
userID in a directory for each package, with symlinks to places in the
user's path. Thus /usr/local/bin/emacs is a symlink to
/usr/packages/emacs-19.25/bin/emacs, so PATH variables stay nice and
short. The system can be configured so root never runs anything in
/usr/local/bin, however this can be infeasible in some instances.
Yes, this does mean that I have to tweak the sources of _every_
program I install on the system.
This also has the handy feature that packages are easy to remove, i.e.
'rm -rf /usr/packages/emacs-19.25' and then clean up the unsatisfied
symlinks.
Here's the hole: If bin owns the /bin or /usr/bin directories, then
the bin user can move binaries aside and wait for root to execute them
(via system startup scripts, 'cron' jobs, etc). If these directories
(which contain programs that really shouldn't change very often) are
owned by root, then one has to break root's security on the system
before being able to plant a trojan or similar file in /bin and
/usr/bin. Now, if you've cracked root already, there's nothing to
stop you...
Doing global 'chown' on the contents of /bin and /usr/bin is a bad idea.
Some UUCP executables expect to be setuid 'uucp' (not root). Certainly
anything without setuid bits can be chowned to root.
Note that any account that owns binary files executed by many users is
a security weakness, and should be secured as well as root.
Scott Schwartz
In NFS for example "root" is mapped to "nobody" (and for a very good
reason too).
If only it worked reliably in 4.1.3_U1. Last time I checked sunsolve
there was a patch for 4.1.3, but not for _U1.
It doesn't stop with NFS either. RPC and most of the other network functions
use unix_auth or some other network uid mapping,
This auth_unix stuff is just insane. Why do vendors cut corners like
this? Kerberos is free, it works, and it does the job. <<Insert
slogans about Total Quality Management and Truly Open Systems Even If
Not Invented Here.>>
Casper H.S. Dik
>Brad Powell writes:
> In NFS for example "root" is mapped to "nobody" (and for a very good
> reason too).
>If only it worked reliably in 4.1.3_U1. Last time I checked sunsolve
>there was a patch for 4.1.3, but not for _U1.
And the patch is not included in _U1, you think? I'm almost sure it is.
>This auth_unix stuff is just insane. Why do vendors cut corners like
>this? Kerberos is free, it works, and it does the job. <<Insert
>slogans about Total Quality Management and Truly Open Systems Even If
>Not Invented Here.>>
Because it's the only thing that's easy to administer.
Until security really starts selling, vendors opt for easy
to use.
Secure RPC isn't secure enough and is cumbersome. Suppose you use
"secure NFS" and one to run a job accessing your files on 100 workstations.
You need to do a keylogin on *all* workstations. And what do you have
to do for a keylogin? Type your cleartext password and there it goes
over the net. And after that, root on those workstations again has access
to your files. Or when you login to the compute server, you have to
type your password or you won't be authenticated. A compute server is
probably a fairer example than using 100 workstations as one
user one workstation seems the only way to do secure networking.
Kerberos cannot be used on multi-user systems. well, okay, you can
use it on multi-user systems. But that defeats the purpose of
Kerberos. Again, one user, one workstation. Also really excludes
compute servers. Has onebig advantage over secure rpc: you don't
have to type your password by rlogin to authenticate yourself
afterwards from the machine you're logged into. Available in
source only in the US (non-US version of K IV is said to be slightly
incompatible.). Source code is a mess, or so they tell me.
Casper
Casper H.S. Dik
>Now it's true that setting up NFS stupidly can open you up to LOTS of
>security problems (can't stop with system users of course, gotta watch
>out for any group related holes, since it's possible for any user to
>became a member of any group), but assuming that it's done correctly, and
>you have bin et.al. securely maintained (*void* password, /bin/false as
>login shell, etc...) then I can't see having executables owned by bin as
>being a "major" hole...
>Or am I completely mistaken?
Well, in a perfect OS, you're right. But there is a catogory of bugs
that allows you to become any uid except root (or read/write aany file
not owned by root). So, better safe than sorry: let root own everything.
If I had had the time, I would have modified my favourite shell (tcsh)
long ago to support "trusted uids". A feature that would stop the
shell from executing any command not owned by a certain set of
users, not without asking first anyway.
Casper
Scott Schwartz
Because it's the only thing that's easy to administer.
Until security really starts selling, vendors opt for easy to use.
My experience has been that doing it right makes it easier to use.
Also, security is the wrong word to use: this is about authentication.
For all intents and purposes NFS ignores file permissions (modulo the
uid 0 hack); that's defective. Vendors should repair defective goods,
and customers should demand satisfaction on that basis.
Secure RPC isn't secure enough and is cumbersome.
But kerberos is secure enough and is not cumbersome.
Kerberos cannot be used on multi-user systems. well, okay, you can
use it on multi-user systems. But that defeats the purpose of
Kerberos.
Not at all. One reason you "can't use it" is because unix security is
so terrible that the bad guys might log on and take control of the
machine and steal your tickets or your password or anything else they
want. That's true of any computer system and has nothing to do with
kerberos or lack thereof. Kerberos does make it possible for users to
authenticate themselves to third parties, which is a prerequisite for
any authorization mechanism (like unix file permissions) to function.
The other reason is that MIT's NFS modifications do only per-mount
filesystem authentication, and they assume that the unauthenticated RPC
traffic won't be modified by attackers on the wire. That's workable
since they disallow multiple users per workstation, but it is a
consequence of their local security policy, not a requirement of
kerberos. RPC can authenticate each request; one could do that instead,
something like secure nfs does. Kerberos provides authentication;
security is what you do with it.
Source code is a mess, or so they tell me.
It doesn't seem particularly messy, at least no more so than anything
else that people happily embrace. K5 is better organized than K4 was,
although it has gotten larger :-(
Jim Jagielski
>bpo...@Sun.COM (Brad Powell) writes:
>>In article q...@geraldo.cc.utexas.edu, ge...@shallot.ots.utexas.edu writes:
>>:Hi all,
>>:
>>On some early version of SunOS /etc was owned by "bin"; thus the intruder
>>could then become root by playing with your /etc/passwd file.
>I think SunOS 4.1.3 is also like this, bin owns /etc !!! Few months
>back, a patch came out which fixed these permission problems.
>>Moral of the story is that "bin" should never own directories where system
>>files are kept, and root should never execute files from a directory that
>>"root" doesn't own.
>Also, better to put /bin/false as the login shell for bin in /etc/passwd.
Of course, if you want to be _really_ safe, you shouldn't stop at directories.
All executables should be owned by root. How about your libraries? Make sure
they are owned by root. Header files in /usr/include? Those too. Any kernel
configuration file? Root 'em. Termlib or termcap entries? Them too.... etc...
In other words, any file that root can even brush against "should" be owned
by root...
Of course, this isn't they way most systems are set up... quite a lot use
the traditional system users (bin, daemon, sys, adm...) for better
organization of files and utilities.
Now it's true that setting up NFS stupidly can open you up to LOTS of
security problems (can't stop with system users of course, gotta watch
out for any group related holes, since it's possible for any user to
became a member of any group), but assuming that it's done correctly, and
you have bin et.al. securely maintained (*void* password, /bin/false as
login shell, etc...) then I can't see having executables owned by bin as
being a "major" hole...
Or am I completely mistaken?
--
#include <std/disclaimer.h>
| Jim Jagielski | j...@jagubox.gsfc.nasa.gov | V: 301 286-5964 |
| NASA/GSFC, Code 734.4 | Greenbelt, MD 20771 | F: 301 286-1719 |
<< I want my TWO DOLLARS !! >>
-- The paperboy
Nick Maclaren
|>
|> In NFS for example "root" is mapped to "nobody"
|> (and for a very good reason too).
|>
|> "bin" is mapped to "bin" "sys" is mapped to "sys" ect....
|>
|> so as a really simple example; say you export your "/usr" filesystem
|> read-write (default).
|>
|> an intruder could, upon gaining root somewhere where he can get to your
|> subnet, NFS mount your "/usr" filesystem; su to "bin" on the the compromised
|> machine (he is root already) and then manipulate *your* /usr/bin binaries.
|> (trojan login?)
|>
|> dozens of variations/tricks I've seen/documented on this attack.
|>
|> It doesn't stop with NFS either. RPC and most of the other network functions
|> use unix_auth or some other network uid mapping,
|>
|> Moral of the story is that "bin" should never own directories where system
|> files are kept, and root should never execute files from a directory that
|> "root" doesn't own.
Actually, this doesn't help much. All the hacker has to do is to put a
trap in your private directory, such that it then inserts a trapdoor
into root access when you next do something (like logon, or use X). And
bingo!
I would favour the following approach:
1) Never NFS export any part of your system writable to any system
whose administrator isn't trusted with YOUR root password. Ditto with
RPC for all privileged accounts (INCLUDING the private ones of system
administrators).
2) Consider moving to DCE or some other environment with some
minimal amount of network-related security. Yes, I know that DCE is
a shambles, not here yet, possibly already dead and all that ....
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cus.cam.ac.uk
Tel.: +44 223 334761 Fax: +44 223 334679