Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Mar 1999 21:15:40 -0600 (CST)
From:      James Wyatt <jwyatt@RWSystems.net>
To:        Robert Watson <robert+freebsd@cyrus.watson.org>
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.4.05.9903141504520.5759-100000@kasie.rwsystems.net>
In-Reply-To: <Pine.BSF.3.96.990314135355.5121G-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Mar 1999, Robert Watson wrote:
> 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.

True, they just take extra space, reads, cache, etc... but not much.

> > 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?

I expect admins who don't usually exhaustively check files before deleting
them to read mail sent to them every night. Backup admins who also get the
mail (we get our customers security mail) can also read it.

> 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.

No, it doesn't: we just don't have user cgi running in the same partition
as the system binaries - that can be a bad idea too. No can hard link to
*anything* systemwise. If I have suid-root stuff in my web tree, I should
be *very* careful of it anyway as there is no retry limit or delay like
telnetd. Of course I can't prevent them from symlinking to /usr/bin/su and
brute forcing a crack. I get logs of that, though.

> 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.

I theory, I like the idea of /tmp on a(n) MFS. It comes up clean and saves
a partition. In practice, I usually have to enlarge swap about exactly as
much as I saved on /tmp. I don't usually have to worry about suid programs
in /tmp, or need them. In fact, prefer noexec on /tmp when I can get it...
When filesystem support RO, noexec, etc. it tells me someone else must
think partitioning of security by filesystem was intended - if not
optimal. /tmp is used for intermediate files and scratch data as I don't
do much mail routing on the laptop either - it's address changes too much.
As my laptop is not usually a security risk, so I usually use just root
and swap as well. I also find that I like /tmp hanging around more on the
laptop than a server when I forget to save the more important intermediate
files. 8{( I also don't have to hunt down users if something fills it up.


> > > > 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?) 

Good point, though I'd never noticed the recommendation, I've always used:

	(cd /here && tar cf - .) | ( cd /there && tar xvf - )

I don't know if it is as efficient, but it works well for everything but
devs on about everything I've been on. Just different approaches, I guess.

> > > 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...

But it can be time consuming. (esp on laptops w/just root filesystem)

> > 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.

I don't trust it either since a friend showed me how to break some of the
race conditions. (Interestingly enough with symlink() on a Tandy 6000)

> > > 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 can't easily tell what is symlinked-to, if I understand this. I can do
things like 'ls -li' to get the inode number and 'find /fs -inum %d -xdev'
to find all the bits. I also like the handy ref counter to cross-check.
How do I find what is linked to vi (esp. in various filesys /usr/bin,
/usr/sbin, /usr/local/bin, ...)? How do I *know* I have all of them with
out a ref count cross-check? I can also typo 'ln -s vi-bim ex' and be
confused for a few minutes by the 'ex: No such file or directory' when I
can see it, but don't recognize the 'ls -l ex' output as another typo.

> I'm just not sure that the consistency issues raised by hard links justify
> the meager benefits.

Please don't "gore my ox" as meager; It's not polite. 8{) Remember that
"Meager benefits" is a *very* relative term. As I said before, I did a lot
of work on systems without symlinks. Took some getting used-to and
resulted in a few extra files (like /bin/rmail was a copy of sendmail),
but wasn't too bad. The designers there thought symlinks were of meager
benefit. They also thought that more than 64K inodes per filesystem was of
meager benefit. 8{( Really, FreeBSD seems to provide every benefit we both
feel we need.

> > > 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.

Better than an English or American one? 8{) Or something... - Jy@



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.4.05.9903141504520.5759-100000>