> Date: Wed, 11 Dec 1996 23:00:01 -0500 (EST)
> From: Greg Alexander <galexand@sietch.bloomington.in.us>
> To: Linux kernel mailing list <linux-kernel@vger.rutgers.edu>
> Subject: Re: Proposal: restrict link(2)
>
>
> On Wed, 11 Dec 1996, Hubert Mantel wrote:
>
> However, for small code-hackers, who do all sorts of funny things to their
> systems, finding a single linux partition with all of the files on it is a
> _very_ common thing. security should not be denied to these systems.
Well, if you only have one filesystem you have a problem. And small code
hackers with only one drive generally are not runing highly-secure systems.
There are some that I know of, but not many.
> However, I don't think that this is necessarily a kernel issue.
> If compatability is hoped to be maintained with more "standard" flavors
> then the commands should probably continue to work basically the same. It
> presents a problem that can and should be easily solved in userspace.
_NO_ There are _WAY_ too many buggy programs out there... and unless you
are willing to be on 20-30 security lists and are quite capible of fixing
on the spot any program that you are running on your system... not just
suid stuff, but anything that is called from cron, that is a server, or
that root may run, then you will need some sort of kernel help on this.
> Having the kernel take care of everything adds to all sorts of
> portability/security problems on other platforms. Even the way that some
Actually, the inability to link to files owned by someone else isn't
really a major problem... I can't really see any time that you would
need to link() to a file that you only have read access to. If you
can write to it (owner/group/other) then you should be able to link to it.
Besides, by link()ing to a file you change it. And if you don't have the
ability to write to it, you should _NOT_ be able to change a file.
symlinks don't count, as they are just pointers to a file that may, or may
not exist. Hard links become the file itself.
> of the includes include other stuff automatically for me has proven to be
> a pain in the butt when trying to port to SunOS (am I seeing funny
> systems, or is every SunOS system's include files really messed up?).
> Being able to assume that there are no hardlinks in /tmp that shouldn't be
> there is not an assumption that I think programs should be able to make.
All too true. But all too common none the less...
Would anything BREAK if we made link() depend on write access? And does
POSIX require that ability?
NOTE: I'm not saying this should be the default behavior. And nobody can make
the argument that it 'promotes stupid security errors' Because it dosn't.
What it _DOES_ is fix the hole that lots of stupid programmers make. And just
doing a stat() before modifying a file may not be good enough... that does
leave fairly obvious race conditions. Besides, I don't like the idea of
someone leaving a program that watches /tmp for "interesting" files, then
hardlinks them before they get erased... If they can make something permanant,
they may be able to use something else to get at it. For example, some hole in
some cron'd process that only execute sonce per hour... what's the odds of a
password change that puts a copy of /etc/shadow in /tmp happining at the exact
time that does? But if they can link("/etc/shadowtmp","/etc/mytmp"); then
they can come back and read it at their leasure...
Now, like I said, do we _REALLY_ like the connotations of being able to link
(and therefore modify) files that we don't have write permissions to?
--Dan