Messages in this thread |  | | Date | Sun, 15 Dec 1996 16:04:34 -0500 (EST) | From | "Adam D. Bradley" <> | Subject | Re: Proposal: restrict link(2) |
| |
On 15 Dec 1996, Kai Henningsen wrote:
> mackin@interlog.com (Cameron MacKinnon) wrote on 13.12.96 in <32B1FACC.2507FBC6@interlog.com>: > > > OK, so I've read the debate about hard links to others' files. Some > > interesting issues have been raised on both sides. Personally I think > > that people who are going to be programming suid had better know what > > they are doing. > > How about doing a library for suid programs, with functions to safely do > all sorts of stuff?
Like open() and stat() files w/ one syscall, and somehow block the prog from ever calling strcpy()? Not a bad idea.
Someone mentioned that the UNIX sockets can now securely pass UID etc; this stirred my memory of the "SUID library" debate (sounded a lot like the link debate of this week), and the closing suggestion: have a root daemon handle lots of the more jittery security issues, and eliminate the need for a program to be setuid to begin with. To mesh it with this idea, perhaps (to maintain source compatibility) programs that would "normally" be made SUID could instead be linked against a "libcsecure", which overrides the iffy functions (file and string handling especially), virtualizes R/E uid's, and so on...(is this sounding a little like C++ objects?)
Quite a project, indeed...but it could (a) maintain compatibility and (b) clear up a lot of concerns about sloppy SUID programing...
Just another wacky idea...
Adam -- He feeds on ashes; a deluded mind has led him Adam Bradley, UNCA Senior astray, and he cannot deliver himself or say, Computer Science "Is there not a lie in my right hand?" Isaiah 44:20 bradley@cs.unca.edu http://www.cs.unca.edu/~bradley <><
|  |