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