Messages in this thread |  | | Date | Fri, 13 Dec 1996 02:43:11 -0500 (EST) | From | Dan Merillat <> | Subject | Re: Proposal: restrict link(2) |
| |
On Wed, 11 Dec 1996, Greg Alexander wrote:
> 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
|  |