[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: suid



On Thu, 12 Feb 1998, Stanislav Malyshev a.k.a. Frodo wrote:

> On Thu, 12 Feb 1998, Peter L. Peres wrote:
> 
> >
> >I don't know why this discussion exists. I am not an expert, but I know
> >that suid anything is a very bad idea, including and especially shell
> "Suid anything" - yes. But suid itself - not. Just use it only when you
> can't do without (least privilege principle).

It is possible to do it such that NOONE except root ever changes
privileges to root.

Also, I strongly favor suid-lockout systems, where a process that drops
its root privileges cannot regain them whatever happens.  

> >You will argue that an X server must be suid to be run by a user, and I'll
> NOT here. there are wrappers and xdm.

Wrappers ? Hehehe. A wrapper that covers all the things an X server
touches on Linux when it starts up must look like an Olympic swimming 
pool cover. It'd be so complex, ITS security bugs would start being
annoying for a few years. ( But there may already be such a beast. Never
seen one though ).

> >There are suid-less solutions for anything. A named pipe in the system,
> Not quite. At least, not in convenient way. At least sudo should be suid
> ;)

So ppl can hack it ? One variant of the 'privileges as low as possible' is
'need to know'. Which means, that ppl who need not run sudo cannot run it
at all in this case. In fact, they can't even see it. Thus, it is not
required at all ;)

> >Also, normal mortal users should not be able to run any kind of command
> >with suid privileges, and certainly no suid scripts of any kind. 
> What about ping? passwd? rewriting all this via pipes and stuff would be
> painful...

Not really. They are halfway there already. passwd is a public danger as
is, anyway. On large systems ping is not ping, someone (the higher local
god) provides a wrapper around it so it pings only once. And it is not
suid (that one) methinks.

> >imho there should be a compiler flag that would be set automatically and
> >prevent any kind of suid for any program not compiled by root, or a list
> Don't get the idea... How compiler knows that program it compiles gonna be
> suid-ed? Or why should I compile under root? Generally, the rule is "never
> go root unless you must"... Just to be sure :)

Ok, I was very tired. Still am. Probably writing b..s..t. But I think that
allowing ppl to keep trying to break in through compilers, suid scripts,
floppy mounts, and by inserting toothpicks into the fan gills and whatever
is a bad idea. Something should be done. 
   
> >of programs allowed to suid in a database built into the kernel. 
> Are you kidding? Have too small kernel?

Aren't you the guys who run about with piles of modules ? The number of
suid programs on a security-conscious machine is so small that by storing
only the inode numbers for them, one should get away with 1024 bytes of
table in the kernel, for 256 such programs. 

A loading from a file at a certain ioctl call (not by itself, as someone
could make a mistake and hang himself out of the system by removing passwd
fromt the list), a parse and a sort, and it's in the kernel.

A call to bsearch for each attempt to exec suid and it's done. And
freezing the session of someone who did that (ran a suid program not
listed) and is not root would conclude matters (this one would be harder
to do, probably farmed out to a script, like request-route, called
suid-violation).

Notice that by storing inodes, any copy of the program would invalidate
that list entry until the table is reloaded. This includes a malicious
copy, and a move by another program over it, shoudl anyone break things
that far. 

The reload would be locked out by another ioctl call, that would
invalidate table reloads until the next reboot. 

This neatly covers the matter of the newbie suiding something and then
crowds getting into his box for months on end.

This is basically an ACL for suid progs ;)

And anyway, it's root who has to know about them, so he'd better.

There is safe-finger and other things that solve the remaining problems.

And now that I come to think of it, it would be a good idea imho to move
/etc/passwd into /proc and make it 'magic' such that a user who calls the
gecos functions can only see his own entry, unless he is root. It's
read-only for mortals anyway. A way should be found for passwd to set the
passwd of the user only. Root would still see the whole thing.

I have said that I am interested in making Slackware more secure before,
and I'm not giving up. 

Peter