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

Re: suid



On Thu, 12 Feb 1998, Peter L. Peres wrote:

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

Well, root really has to be very tired to try to changes his privilegies
to root... :))


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

That's another thing. That's good. Done root stuff - drop root.

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

Just read some security list archives. Bugtraq, linux-security... I think
Debian has it in standard setup. Maybe others.


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

Security by obscurity is BAD. Crackers know about your system *at least*
as much as you do (except passwords, etc.). Build on that. Or you will
find out some amusing facts about what a teenager with unlimited free time
can discover on your system for his amusement...

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

Hmm... I thought it, like, opens raw sockets... 
"socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3", quoth strace.
Anyway, show me suid-less system that is fitted for the user (developer?
student?) - I'll agree.

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

well, if you take it so broadly - they only solution is the power switch :). 
To err is human, so programs will have bugs, and people will find them,
and good ones will post them to bugtraq, and bad ones will try them on
your computer... 
 
>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. 

And then your upgrade it, and inode changes, and you cannot login,
cannot su, cannot correct it... What for, all this? just mount everything
except /bin nosuid, and you've done.

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

Well, you may remove passwd and issue ioctl... ;)
It's amusing what typing habit and routine and lack of sleep can do...

>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

what is "freezing the session"? Unix is multiuser, multiprocess system...
do you mean sending SIGSTOP to all user's processes??? Well, I'd look on
you when you get such a brick on your head.
And it still can login again anyway... to lock out account also? 
Don't you think this is like nuking entire city if one citizen has crossed
a street on the red light?

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

hmm... seems it's too complicated to be useful. 

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

Linux has a patch which removes suid on write. Will perfectly fit
this purpose. To be found on Linux-MAMA. And I don't really get why
writing to a file must change it's inode? And what prevents me from
deleting old file and getting the same inode for a new one (a couple of
tries, if I'm unlucky), if I already have rights to write into /bin?

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

Reboot on upgrade? Do I smell NT odours?

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

Well, if the newbie is root, he'll add this program to the list of "can
execute", if it did suid it. Probably, he'll even write script to do both
things at once and will use it always.

>This is basically an ACL for suid progs ;)

ACL is another thing, AFAIK. 

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

Well, if the root is a said newbie...

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

What's bad in user seeing other user's usernames, real names, etc? Just
don't get an idea.

Seems that there simply should be audited, trusted programs that have to
be suid (like sudo, and couple of others), and the rest shouldn't. That's
all.
--
frodo@sharat.co.il	\/  There shall be counsels taken
Stanislav Malyshev	/\  Stronger than Morgul-spells
phone +972-2-5369213	/\  		JRRT LoTR.
http://www.sharat.co.il/frodo/   whois:SM719-RIPE@whois.ripe.net