Messages in this thread |  | | Date | Fri, 13 Dec 1996 20:00:45 -0500 (EST) | From | Illuminati Primus <> | Subject | Re: Proposal: restrict link(2) |
| |
On Fri, 13 Dec 1996, Dan Merillat wrote:
> > > > 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 >
Why not just make link() create a symlink instead of throwing it away alltogether (yes and i know it might break some weird program somewhere, but it will do away with your supposed chown() bug)..
-vermont@gate.net
|  |