All of lore.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>,
	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: Tue, 19 Sep 2006 00:09:43 -0400	[thread overview]
Message-ID: <450F6D87.7090604@gentoo.org> (raw)
In-Reply-To: <20060919034601.97733.qmail@web36610.mail.mud.yahoo.com>

Casey Schaufler wrote:
> --- Joshua Brindle <method@gentoo.org> wrote:
>   
>>> 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.
>>     
>
> Oh that. Sure, we used capability bracketing
> in the code, too. That makes it easy to
> determine when a capability is active. What,
> you don't think that it's possible to analyze
> source code? Of course it is. Refer to the
> evaluation reports if you don't believe me.
>
>   
When I see an analysis of every line of source code on an average Linux 
machine then I might believe you (if you'll grant that no software can 
ever be installed on it afterward without being analyzed) but until then 
I'll stick with a centralized policy. I doubt many others will be 
satisfied with that limitation.

Bracketing hardly makes it analyzable, how can you possibly know if the 
bracketing happened? You *believe* it will and therefore you say that 
the bracketed code is safe but in reality this is a discretionary 
mechanism and you have zero assurance that there is any security 
whatsoever, no thanks, I'll pass.

  reply	other threads:[~2006-09-19  4:09 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
2006-09-19  3:46                   ` Casey Schaufler
2006-09-19  4:09                     ` Joshua Brindle [this message]
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=450F6D87.7090604@gentoo.org \
    --to=method@gentoo.org \
    --cc=casey@schaufler-ca.com \
    --cc=david.madore@ens.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.