Re: Secure-linux and standard kernel
Vadim E. Kogan (vadim@vadim.gem.net)
Fri, 26 Jun 1998 12:54:20 -0700
MOLNAR Ingo wrote:
>
> On Fri, 26 Jun 1998, Stephen C. Tweedie wrote:
>
> > > i think you are overlooking the fact that the kernel only evaluates this
> > > 'extra info' if the given binary is a setuid root binary. Which means it's
> > > contents are absolutely trusted.
> >
> > You are overlooking the fact that in a posix.6 capabilities
> > environment, there _is_ no trusted root user, and no single superuser
> > privilege. The entire point of the capability mask is to eliminate
> > that.
>
> the RL point of the capability mask is not to remove root, the point is to
> reduce risks of compromising security, given a constant number of
> programmer-created errors in security-relevant code ...
>
> yes, the almighty root 'suser()' call is gone, but theres no much point in
> removing the root _account_, except in some very paranoid setups. Someone
> still has to fix up stuff when a system gets broken ...
Not really. Yes, you need admins. But it doesn't mean that there is one
admin with uid 0, who can read/write all files, fix/break shuff, etc.
And this is all aver the place in kernel now. Like that recent problem
with /proc, where if process did set*id() all files in it's /proc/<pid>
dir will be owned by root, and be READABLE by root. There still should
be root in the meaning of "the guy who makes sure general stuff runs
Ok". But there might be other services/files/etc, that are maintained by
separate people. And that stuff should NOT be readable/changable by
root. No matter what happens, there is a separate person to fix that
part.
>
> the point is not to remove the administrator (kinda silly, isnt it, except
> maybe in the military, yes they kinda love solving problems by talking
> them away), the point is to reduce/divide the power of those zillion
> system-critical daemons and setuid-root binaries that rarely need that
> much power.
Idea is good, but I'd prefer to remove Administrator and create
administratorS. And forget that word "root" forewer, as it doesn't mean
anything. Sucurity Admin, FTP Admin, blabla admin. Maybe sometimes in
one person. Spliting it further will give you even more flexibility.
Let's look at backup process. Instead of having Backup Admin, you can
have system permissions like:
<can initiate backup>
<can cancel backup>
<can restore>
<can change backup config>
it all can be assingned to one person if you want. But at the same time
you can have a user that is just a regular guy, who works late sometimes
and you want to make sure that backup happens after he's done. So you
give him right to initiate backup. He can't change parameters (config),
he can't do anything with it, but he can start the process. And it's
very usefull, as in most situations you don't change config and don't
restore, unless there is a problem. But you have dummies around all the
time, so make 'em do the backups!
Same can apply to programs, so that when a user starts program his
permissions are ANDed with program permissions, so you can have double
protection.
>
> [and, if you want, you can remove root too in the Posix way, just forbid
> setting any inode mode to setuid-root in sys_chmod() except when CAP_SUID
> is raised.]
>
> -- mingo
Another big mistake I see in this thread is that ppl assume that the guy
"root" (who also boots computer) can't change kernel. Or boot DOS and go
look at disk. Or other things you can do when you have a little bit of
power or physical access to the computer. That's no good. You can't
archieve any good security if you base it on trust in several human
beings.
Well, maybe one can say that Im too paranoid, but IMHO it's better to be
paranoid than spend all the time hoping that nothing will happen and
when it happens cry and try to fix. The main difference between real
admin and admin "on paper" is that real admin sits there and plays
tetris, while admin "on paper" sits there and monitors the system :))
Vadim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu