From: Casey Schaufler <casey@schaufler-ca.com>
To: Linux Kernel mailing-list <linux-kernel@vger.kernel.org>
Cc: Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: patch to make Linux capabilities into something useful (v 0.3.1)
Date: Wed, 6 Sep 2006 18:01:27 -0700 (PDT) [thread overview]
Message-ID: <20060907010127.9028.qmail@web36603.mail.mud.yahoo.com> (raw)
In-Reply-To: <20060907003210.GA5503@clipper.ens.fr>
--- David Madore <david.madore@ens.fr> wrote:
> I understand your point. But if we want these
> under-privileges to
> follow the same inheritance rules as the
> over-privileges provided by
> capabilities (were it only to make things simpler to
> comprehend),
> doesn't it make sense to implement them in the same
> framework?
I'm certainly not convinced that you'd
want that. Think of all the programs that
would have to be marked with CAP_FORK.
> Rather
> than trying to reproduce the same rules in a
> different part of the
> kernel, causing code reduplication which would
> eventually, inevitably,
> fall out of sync... I think it's easier for
> everyone if under- and
> over-privileges are treated in a uniform fashion.
This again assumes that you want to require
that in general processes run with some
capabilities.
> Perhaps that's not
> what POSIX intended, but I don't think "not what was
> intended" is a
> sufficient reason for backing away from something
> that might be
> useful. Do you have a specific problem in mind?
You betcha. (That's Minnisotan for "Yes indeed")
In our TCSEC B1 (Old person speak for LSPP)
evaluation we had to put way too much effort
into explaining why certain operations that
had nothing to do with the system security
policy (e.g. compute resource limitations)
required privilege. These operations had
no security implications at all, but since
they required privilege they were assumed to
have dire consequences should they be abused.
If you introduce an "underprivileged" process,
you immediately relegate what are currently
unprivileged processes to the realm of
privileged processes. All of a sudden any
process that does fork() requires additional
scrutiny because it uses privilege. You
won't convince any evaluator that there is a
difference between "having a capability" and
"not having lack of capability".
On the other hand if you have "additional
restrictions" available (as in an LSM) that
are not part of the policy enforcement
mechanism there should be no problems.
> However, the suggestion makes sense: if I can't
> convince the Powers
> That Be that implementing under-privileges with
> capabilities is a Good
> Thing (and I can see that it will be a serious
> problem), I'll try the
> LSM approach.
Further, you can assign any semantic that
makes sense to you. Heaven knows, the POSIX
calculation (from any of the DRAFTS) has
proven to be contentious. Especially in the
inheritence rules on exec.
Casey Schaufler
casey@schaufler-ca.com
next prev parent reply other threads:[~2006-09-07 1:01 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-05 21:26 David Madore
2006-09-06 0:27 ` Casey Schaufler
2006-09-06 10:06 ` David Madore
2006-09-06 13:26 ` David Madore
2006-09-07 0:11 ` Casey Schaufler
2006-09-07 0:32 ` David Madore
2006-09-07 1:01 ` Casey Schaufler [this message]
2006-09-07 1:29 ` David Wagner
2006-09-07 16:00 ` Casey Schaufler
2006-09-07 18:33 ` David Wagner
2006-09-07 17:34 ` David Madore
2006-09-07 19:38 ` Bernd Eckenfels
2006-09-07 23:00 ` Pavel Machek
2006-09-08 1:22 ` Bernd Eckenfels
2006-09-08 10:45 ` Pavel Machek
2006-09-08 16:08 ` Casey Schaufler
2006-09-08 14:39 ` Pavel Machek
2006-09-08 19:10 ` Bernd Eckenfels
2006-09-07 22:54 ` Pavel Machek
2006-09-08 4:10 ` David Madore
2006-09-08 10:52 ` Pavel Machek
2006-09-08 22:51 ` David Madore
2006-09-09 0:11 ` Casey Schaufler
2006-09-09 11:59 ` Pavel Machek
2006-09-09 11:40 ` Pavel Machek
2006-09-10 10:41 ` David Madore
2006-09-10 13:06 ` Pavel Machek
2006-09-10 14:25 ` capability inheritance (was: Re: patch to make Linux capabilities into something useful (v 0.3.1)) David Madore
2006-09-10 22:42 ` Pavel Machek
2006-09-11 16:00 ` Casey Schaufler
2006-09-11 17:39 ` David Madore
2006-09-09 0:59 ` patch to make Linux capabilities into something useful (v 0.3.1) David Wagner
2006-09-09 12:49 ` David Madore
2006-09-09 23:18 ` Theodore Tso
2006-09-10 10:13 ` David Madore
2006-09-10 12:36 ` Pavel Machek
2006-09-10 23:24 ` Theodore Tso
2006-09-11 8:09 ` Pavel Machek
2006-09-06 18:25 ` Serge E. Hallyn
2006-09-06 22:27 ` David Madore
2006-09-07 0:04 ` David Madore
2006-09-07 23:06 ` Serge E. Hallyn
2006-09-08 4:16 ` David Madore
2006-09-07 6:43 ` Jan Engelhardt
2006-09-07 23:02 ` Serge E. Hallyn
2006-09-08 1:08 ` David Madore
2006-09-08 1:31 ` Serge E. Hallyn
2006-09-08 21:45 ` David Madore
2006-09-07 18:21 ` James Antill
2006-09-07 18:33 ` Kyle Moffett
2006-09-07 20:05 ` James Antill
2006-09-08 4:00 ` David Madore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060907010127.9028.qmail@web36603.mail.mud.yahoo.com \
--to=casey@schaufler-ca.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome