public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joshua Brindle <method@gentoo.org>
To: casey@schaufler-ca.com
Cc: David Madore <david.madore@ens.fr>, Pavel Machek <pavel@ucw.cz>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel mailing-list <linux-kernel@vger.kernel.org>,
	LSM mailing-list <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH 3/4] security: capabilities patch (version 0.4.4), part 3/4: introduce new capabilities
Date: Mon, 18 Sep 2006 20:25:27 -0400	[thread overview]
Message-ID: <450F38F7.6080006@gentoo.org> (raw)
In-Reply-To: <20060918160217.97076.qmail@web36601.mail.mud.yahoo.com>

Casey Schaufler wrote:
> --- Joshua Brindle <method@gentoo.org> wrote:
>
>   
>> And that is just practical stuff, there are still
>> problems with
>> embedding policy into binaries all over the system
>> in an entirely
>> non-analyzable way, and this extends to all
>> capabilities, not just the
>> open() one.
>>     
>
> Your assertion that directly associating
> the capabilities with the binary cannot
> be analysed is demonstrably incorrect,
> reference Common Criteria validation
> reports CCEVS-VR-02-0019 and CCEVS-VR-02-0020.
>  
> The first system I took through evaluation
> (that is, independent 3rd party analysis) stored
> security attributes in a file while the second
> and third systems attached the attributes
> directly (XFS). The 1st evaluation required
> 5 years, the 2nd 1 year. It is possible that
> I just got a lot smarter with age, but I
> ascribe a significant amount of the improvement
> to the direct association of the attributes
> to the file.
Thats great but entirely irrelevant in this context. The patch and caps 
in question are not attached to the file via some externally observable 
property (eg., xattr) but instead are embedded in the source code so 
that it can drop caps at certain points during the execution or before 
executing another app, thus unanalyzable.

  reply	other threads:[~2006-09-19  0:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-10 13:37 [PATCH 1/4] security: capabilities patch (version 0.4.4), part 1/4: enlarge capability sets David Madore
2006-09-10 13:41 ` [PATCH 2/4] security: capabilities patch (version 0.4.4), part 2/4: change inheritance semantics David Madore
2006-09-10 13:42 ` [PATCH 3/4] security: capabilities patch (version 0.4.4), part 3/4: introduce new capabilities David Madore
2006-09-10 16:23   ` Alan Cox
2006-09-10 16:09     ` David Madore
2006-09-11  8:06       ` James Morris
2006-09-11 12:03         ` Joshua Brindle
2006-09-11 16:22           ` Casey Schaufler
2006-09-17 18:06           ` Pavel Machek
2006-09-10 17:56     ` Joshua Brindle
2006-09-10 20:03       ` David Madore
2006-09-11  6:10         ` Jan Engelhardt
2006-09-11  6:51           ` David Madore
2006-09-11 13:42         ` Stephen Smalley
2006-09-17 18:14       ` Pavel Machek
2006-09-17 20:39         ` Joshua Brindle
2006-09-17 21:16           ` David Madore
2006-09-18 11:46             ` Joshua Brindle
2006-09-18 11:58               ` David Madore
2006-09-18 12:04               ` Pavel Machek
2006-09-18 12:12                 ` Joshua Brindle
2006-09-18 16:02               ` Casey Schaufler
2006-09-19  0:25                 ` Joshua Brindle [this message]
2006-09-19  3:46                   ` Casey Schaufler
2006-09-19  4:09                     ` Joshua Brindle
2006-09-19 15:54                       ` Casey Schaufler
2006-09-19 18:27                   ` Pavel Machek
2006-09-10 13:44 ` David Madore
2006-09-10 13:46 ` [PATCH 4/4] security: capabilities patch (version 0.4.4), part 4/4: add filesystem support 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=450F38F7.6080006@gentoo.org \
    --to=method@gentoo.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=casey@schaufler-ca.com \
    --cc=david.madore@ens.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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