[lkml]   [1996]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Proposal: restrict link(2)

On 15 Dec 1996, Kai Henningsen wrote:

> (Cameron MacKinnon) wrote on 13.12.96 in <>:
> > 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++

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

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

 \ /
  Last update: 2005-03-22 13:38    [W:0.045 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site