Date: Sun, 14 Mar 1999 14:07:02 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: James Wyatt <jwyatt@RWSystems.net> Cc: The Unicorn <unicorn@blackhats.org>, Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu>, freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <Pine.BSF.3.96.990314135355.5121G-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.05.9903141112050.5759-100000@kasie.rwsystems.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Mar 1999, James Wyatt wrote:
> On Sun, 14 Mar 1999, The Unicorn wrote:
> > On Sat, Mar 13, 1999 at 07:26:52PM -0500, Robert Watson wrote:
> > > BTW, I'd really like to get rid of hard links -- they allow users to
> > > retain copies of setuid files after the owner thinks they are deleted.
> > > I.e., user creates a hard link to /usr/sbin/somesetuidbin to
> > > /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have
> > > removed the risk of the now known buggy somesetuidbin.
>
> To quote Bill The Cat: Ack! Phht!
> No! Please, No! I use arg0 in a lot of my programming when it's useful to
> have common code that does related, but different, things. (Please look at
> the boot disk, vi/ex/view/nvi/nex/nview, gzip/gunzip/zcat/gzcat, gcc/cc,
> compress/uncompress, etc...) If you want to find more, just try:
>
> find / -links +1 -type f -print | xargs ls -l | more
symlinks, when executed, pass the symlink name as arg0.
> This is just too useful to most folks to save the sysadmin who doesn't
> read their nightly security mailings. It is also why I like a /tmp filesys
> (as well as a /home) filesys on machines with real users. Don't let them
> link on drives w/important binaries and don't let them vi ~/bigfile to
> fill-up /tmp and hurt everyone using '/'! Ensure, if you have one, that
> ~ftp/incoming is a separate filesys too. 8{)
There seems to be some contradiction here: you want users without
extensive security experience and unwilling to look at nightly security
mailings to know how to partition systems in the manner you describe?
What about users who use setuid so that their CGI scripts execute as their
own UID? This means having more than one user per partition is a bad
idea.
The merits of a MFS /tmp (cleared at boot, restricted in size, etc) should
not be confused with the merits of secure file system behavior. All I
want is for it to be safe for me to have a setuid binary on the same file
system as a temporary directory. File systems were not intended to be the
partitioning points for security domains -- they are for file storage as
binary blobs :-). Don't overload security characteristics onto local hard
disk arrangement. I know that this already happens somewhat, but I'd like
to try and reduce it in the name of KISS and consistency.
Especially given how many people run with so many different partition
arrangements. Personally, on notebooks, I like to have everything except
tmp on one partition, and have tmp on MFS. This means that the slack
space from each partition is not wasted in places where it won't be needed
(not much mail delivery on my notebook). On the other hand, it doesn't
meet the requirement that each user home directory, world-writable
directory (*/tmp, texmf, etc), etc, be on a different partion :-). And it
does end up being a multi-user machine (a poor distinction except from the
point of view of performance operation in my view) because sometimes I
need to access it remotely, or give other people access to files on it.
> > > Also, since directory permissions act as a cumlative masks on the
> > > permissions of files held in them, it can be hard to revoke access to a
> > > file you own--someone else may have hard linked it elsewhere in the fs
> > > without your knowledge (something they can do as long as they own the
> > > target directory). Given that hard links already cause inconsistent
> > > semantics in the name space for users, and aren't properly preserved in
> > > tar, etc, I think they don't contribute much.
>
> Geez, even SCO Xenix tar got this right. Dump can't miss it and cpio gets
> it right (even on devs!); so who's tar broke this? (Minix doesn't count 8{)
Recursive cp? (The intuitive, simple, *man page recommended* way to copy
a directory from one hard disk to another?)
> > They cause inconsistent semantics, but they are recorded in the inode as
> > the number of links to the file the inode holds information on. Therefor
> > any admin who is worth the money they receive for doing their task will
> > know that if the number of links to a file is greater than one another
> > hard link must exist. Searching the filesystem for another name
> > referring the same inode is then not a really hard thing to do...
>
> Uh, I know a lot of admins that I consider 'worth their salt' who don't
> check link counts (or maybe even notice them in an 'ls -l') before
> removing a file. I don't think system upgrade scripts do it either.
And "checking" still allows for race conditions. Especially when
automated. And I agree that checking should not be necessary.
> > Have a look at ls -l `which vi view ex` and think again about what hard
> > links contribute (then again similar functionality might be constructed
> > using soft-links; but they are much harder to administrate (read: keep
> > under control))
>
> Symlinks do not prevent the original binary from being unavailable. Please
> remember that files don't really go away until all links are zero and no
> more filedescs are open on them. Hey, if 'the founders' had meant for
> symlinks to be used over hard links, there would have been an 'ls -h'
> flag, right? 8{)
Symlinks don't prevent the filedesc behavior from happening. They do not
allow for the refcount, but the solution that comes to mind is actually
more intuitive:
mv vi vi-bin
ln -s vi-bin vi
ln -s vi-bin view
Now you replace the one vi-bin binary and all of vi is upgraded. And it's
easy to see what files are linked to other files--with hard links it can
be quite hard.
I'm just not sure that the consistency issues raised by hard links justify
the meager benefits.
> > Just my 0.02 euro.
>
> This means it's euro-pinion? What's the conversion rate? - Jy@
Damned if I know, and I'm English. (Of course, I'm English but living in
the US :-). But clearly a European point is far better.. or something.
Robert N Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C
Carnegie Mellon University http://www.cmu.edu/
TIS Labs at Network Associates, Inc. http://www.tis.com/
Safeport Network Services http://www.safeport.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990314135355.5121G-100000>