From: Casey Schaufler <casey@schaufler-ca.com>
To: David Wagner <daw-usenet@taverner.cs.berkeley.edu>,
linux-kernel@vger.kernel.org
Subject: Re: patch to make Linux capabilities into something useful (v 0.3.1)
Date: Thu, 7 Sep 2006 09:00:55 -0700 (PDT) [thread overview]
Message-ID: <20060907160055.17688.qmail@web36604.mail.mud.yahoo.com> (raw)
In-Reply-To: <ednsma$hbt$1@taverner.cs.berkeley.edu>
--- David Wagner <daw@cs.berkeley.edu> wrote:
> Casey Schaufler wrote:
> >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.
>
> Well, this is sounding like a pretty weak argument.
That all depends on how important getting
an evaluation complete is to you. And, they
do have a point, which is why does it make
sense to use the same privilege mechanism
for you security policy as you do for your
resource management policy.
> It sounds like what you are saying is the evaluators
> were not thinking
> straight when they gave you a hard time about your
> efforts to do a
> better job of implementing the principle of least
> privilege.
No, they were very clear that they felt that
use of the privelege ought to be an indication
that policy was being violated, and they were
correct. The issue was that the system made
it difficult to distinguish between violations
of the security policy and violations of the
resource management policy.
> If I
> understand the gist of what you are saying
> correctly, you reduced the
> privilege on some processes, and the result was that
> they complained
> more loudly than if you had done nothing. If so,
> that's pretty lame.
> That doesn't sound to me like the evaluators were
> thinking very clearly.
No, the issue was that every use of the
privilege mechanism, even when it was not
relevent to the security policy, required
investigation and explaination.
> And if the evaluators don't really understand how to
> think clearly about
> security, why should we pay any attention to them,
> anyway?
Because it's cool to have the hand-calligraphed
certificate hanging on your office wall.
> I see no
> reason to design the Linux kernel around the whims
> of those who don't
> understand the technical issues.
The evaluatee gets to explain the technical
issues to the evaluators. That's the challenge.
The areas that require the most explaination
are typically those that could use refinement.
> Who cares about what the evaluators
> think, if they don't have their head screwed on
> straight? Personally,
> I care more about technical merit than about
> pleasing folks who don't
> understand security.
Much of the community's understanding of
security has come about because evaluators
asked unpleasant questions that required
hard thinking to answer. The SELinux effort,
for example, represents a directed effort
to "do better" than the Unix B1/CMW systems.
Don't underestimate evaluators.
Casey Schaufler
casey@schaufler-ca.com
next prev parent reply other threads:[~2006-09-07 16:00 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
2006-09-07 1:29 ` David Wagner
2006-09-07 16:00 ` Casey Schaufler [this message]
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=20060907160055.17688.qmail@web36604.mail.mud.yahoo.com \
--to=casey@schaufler-ca.com \
--cc=daw-usenet@taverner.cs.berkeley.edu \
--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
all inboxes | Powered by JetHome®