[I've decided to jump into tech-kern, so I'm cc-ing there; please cc:
 me for the next day or so until I can get subscribed for certain]

On Thu, 15 Apr 1999, Greg A. Woods wrote:

# [ On Thursday, April 15, 1999 at 00:58:16 (-0700), Gandhi woulda smacked you wrote: ]
# > Subject: Thought for the day...
# >
# Exactly.  Set-id is designed to go through the filesystem because that's
# the best way to ensure integrity of the code that it is about to be
# given new privileges.  That's also why most modern systems have been
# fixed so that writing to a set-id file turns off the set-id bits unless
# the writer is (already) the super-user.

My thoughts too, according to the current paradigm.  I wouldn't change
those write/change semantics.

# With your proposed scheme you may as well just make /bin/sh set-id to
# the target user and/or group and be done with it because sooner or later
# someone will foil your "privilege broker" into giving away privs to a
# piece of un-trustworthy code that'll just run /bin/sh anyway.  ;-)

Everything is fool-able on the first go-round.  Security evolves.
Nonetheless, this is precisely the kind of input I was looking for!
Thanks!

# If you can come up with some scheme where the privilege broker can
# reliably get an fstat() of the open "text" file for the target process
# and can ensure that the process' text segment is unwritable, then
# perhaps you'd be a little safer, but I'm not really sure what this buys
# you.  The broker can just as easily make available a setuid binary to do
# the same thing.  If you've got processes that have to change privileges
# so fast that they'd be hindered by exec()ing a set-id binary then I
# think you've got a more basic design problem with your application.

I just thought that not needing to fiddle with fork/exec in order
to achieve secure setid would be more elegant.

Thankks for the input.



				--*greywolf;
--
People who cannot be persuaded to use turn signals or ashtrays while driving
should not be permitted to drive.