lkml.org 
[lkml]   [1999]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: caps in elf, next itteration (the hack get's bigger)
Hello.

On Tue, Apr 13, 1999 at 08:28:58AM +1000, Richard Gooch wrote:

> This to me is one of the real blind-spots of some people who are
> pushing capabilities. There is absolutely no need to remove the
> privileges of the root account. By default root has all capabilities.
>
> Think about it: you will need *some* account* with the abilility to
> grant caps anyway. So root is it.

The way I see it, this needn't be the case. I believe what you are thinking
is a chicken and egg trap - but, not as with chickens and eggs - it is easy
to escape from without extensive biological study.

When you initially set up a capabilities enabled system, you'll need some
'root' account that would be able to set the CAP_SETFCAP capability.
However, after a short while, you'll write a 'capabilities granter' - a
program that, based on its own internal security checks (users, groups, time
of day, mood of CPU), would grant capabilities to binaries. This program
would have the CAP_SETFCAP bit (you would give it that using your root
account), and as soon as this program is functional and correct, honoring
capability setting requests properly, you can throw away the root
account. You no longer have any use for it - it is just a security hazard,
because it has total control.
(Obviously, a Linux distribution would come preinstalled with capabilities).

Now, I don't know how practical this is - but this is what a capabilities
based systems seem to be all about. I think that it makes system
administrating more complicated, because you can no longer use regular
programs to control "the world" (you can't even use the 'chown' binary
without making it capabilities aware, to change ownership of files root - or
whatever your new administrator account is - don't own [Actually, you can,
using the effective flag on the binary. But doing that for all executables
that might be used by the administrator is foolish. Or maybe it isn't?]).

This scheme moves administration from the hands of the kernel to the
hands of user tools, in a way. Is this a good thing? I don't know.
But I guess, and hope, the capabilities system in Linux would allow a user
to choose between these two options (maybe with a boot-option) - with god,
or without god... home users and non-paranoid admins would probably
choose the former.

Another approach might be to add a fourth set of process capabilities - a
persistent set. This set would always be active, regardless of what is
running. This would allow an administrator to run some utility that would
grant him persistent capabilities - and from this point (in a subshell),
this user would always be able to use his elevated capabilities without the
need for capabilities aware processes. This breaks the standard, and is not
terribly secure either, but it is a useful behavior.

It is entirely possible that I messed up everything above, but this is what
I think capabilities are.

> The major practical benefit that capabilities provide is that you can
> have privileged binaries that have *only* the privileges that they
> need, and no more. Having a root account with full privileges is
> completely orthogonal to this.

Exactly. It is still a security risk.

Nimrod

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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