lkml.org 
[lkml]   [1998]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2.1.97] more capabilities support
Alexander Kjeldaas writes:
> On Sun, Apr 19, 1998 at 03:17:54AM -0700, Andrew Morgan wrote:
> > + 1.1.2 File capabilities
> > + 1.1.2.1 Inheritable
>
> This is the "allowed" set. [I use this term since it is much clearer
> in order to understand what is going on].

I have just copied the names out of the POSIX draft (section 25.1.1.3).

> > + are assumed to have { ~0 } Inheritable capabilities.

> No, this is not correct. On file systems without capability support,

This was a stupid typo.. I clearly wrote this part of the doc without
thinking. The patch does not enforce what I have documented -- I have
not changed the symantics which continue to do what you say. In this
area, I only cleaned up that code to abstract the form of the
capability sets (this will make it easier to increase the size of the
capability sets without rewriting code).

> * Since we have a CAP_SETPCAP capability (set process' capabilities)
> we can implement file-system capability support using a daemon.

This is a _very_ broken hack! POSIX does _not_ define CAP_SETPCAP for
a good reason. This capability should be removed. With out of bounds
elevation of priorities it is very hard to demonstrate that your
security model has no holes. Without this hack process capabilities
are _only_ set in well defined ways: with a system call from the
to-be-affected process and when a file is exec()'d.

I would strongly urge that this capability is removed.

> * It would arguably be better to have it as a per file system mount
> option.

The compatability stuff seems to require that the filesystem is not
mounted setuid for an exec to "increase" the number of capabilities a
process acquires. Obviously, it makes sense that any filesystem that was
capable of storing capabilities could have these attributes regulated
with a mount option -- much like you can turn suid off.

> > + This set must have either all capabilities raised or all capabilities
> > + lowered. It is used to indicate whether the program knows about
> > + capabilities. If this set has capabilities raised, the program will
> > + start with all of its Permitted capabilities in its Effective set. If
> > + this set is empty, the program will start with an empty Effective set,
> > + and will have to explicitly raise the capabilities it needs.
> > +
>
> This is a single bit saying whether the executable knows about
> capabilities (internally it's represented as a bit mask however).

> This is the "forced" set. It is also read as { 0 } on a file system
> without capabilities support.

Again, this is non-POSIX speak. If you want to use these words it is
fine -- especially if it makes things clearer. I have added them to
my working draft.

> > + 1.3 Compatibility mode
> > +
> > + The historical situation, of the superuser being omnipotent, is
> > + partially preserved following a system call to sys_exec(). This
>
> ..and on set*uid calls.

Whilst this is probably the correct thing to do, this is not yet
implemented in the kernel.

> > + 3 non-setuid binaries directly inherit the capabilities of the
> > + process that sys_exec()s them.

Agreed, this is incorrect, it was late last night... I should say I
wrote all of the text without looking much at the code. Then I went
to work on the code and worked out what it was doing. but, of course,
forgot to fix the documentation.

> > + 1.3.2 Discussion
> > + Firstly, we note that this backward compatibility has only one effect
> > + on systems that are not capability aware:
> > +
> > + Point 2, of section 1.3.1, implies that such binaries
> > + inherit the EUID of root, but none of root's kernel level
> > + privileges.
> > +
>
> No this is not correct. When root runs a non-root setuid program, the
> effective uid of the resulting process is _not_ 0. However, the real
> uid is 0. Letting the permitted set of the resulting program be set
> but not the effective makes perfect sense.

This is actually what I am saying. It is equivalent to what you say
because of the statement that preceeds the paragraph in question. The
important words are "systems that are not capability aware" -- which
means no executables on the system know how to raise permitted
capabilities to become effective capabilities as well as no filesystem
support for capabilities. The point I am trying to make is
that if a process does not have "effective" capabilities then it is
unable to excercise any privileges.

> > + Secondly, on a system that runs binaries which are capability aware,
> > + without setting SECURE_NOROOT mode, it is possible to further restrict
> > + the root account:
> > +
> > + Point 1, of section 1.3.1, implies that a parent process
> > + can reduce its Inheritable capabilities and thus prevent any
> > + of its children from _ever_ acquiring all/any of root's kernel
> > + level privileges. An immediate consequence of this is that it
> > + becomes possible to implement escape proof sys_chroot() cells.

> This does not depend on the SECURE_NOROOT setting. The only way you
> can increase your effective capabilities beyond your inheritable ones
> is if you somehow, through exec or other means, get "forced"
> capabilities. "Forced" capabilities can either come from a

Obviously this text was not clear. On a system without filesystem
support for capabilities, the maximum number of capabilities that a
setuid-root binary can obtain in any way is equal to the "Inheritable"
set of capabilities. This is a feature (I am ignoring the broken
CAP_SETPCAP idea).

It depends critically on SECURE_NOROOT being unset since when it is
set, setuid-root binaries do not get their capabilities automatically
raised. Without filesystem support for capabilities setting
SECURE_NOROOT is a VERY BAD idea ;^)

> capability-aware file system during exec (which we don't have
> currently), or from another process having the SETPCAP capability.

I've already stated that the SETPCAP capability is a broken idea.

[lots of text condensed to the following]:
> Another point is that the system calls in your patch doesn't support
> setting capabilities on other processes. This is needed to implement
> the "capability-daemon".

Again, this is a broken idea. There is no value in having such a
scheme. The whole POSIX model is carefully crafted to avoid the
potential for "holes" of this type. I strongly feel that building
this in, undermines the integrity of the excellent capabilities model.

Best wishes

Andrew

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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