Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Crispin Cowan]

Chris Wright wrote:
> * Chris Mason ([EMAIL PROTECTED]) wrote:  
>> I'm sure people there will have a different versions of events.  The
>> one part that was discussed was if pathname based security was
>> useful, and a number of the people in the room (outside of 
>> novell) said it was.  Now, it could be that nobody wanted to argue
>> anymore, since most opinions had come out on one list or another by
>> then.  
>> 
> Indeed.  The trouble is that's too high level compared with the actual
> implementation details.  AA is stalled because it has failed to get
> VFS support for it's model.  I don't see a nice way out unless it
> changes it's notion of policy language (globbing is the tough one)
> or gets traction to pass dentry/vfsmount all the way down.  Paths are
> completely relevant for security, esp. when considering the parent dir
> and the leaf (as in forward lookup case).
To do pathname-based access control in any way, the LSM must be able to
obtain the pathname of an accessed object. The discussion should be
about the best way for an LSM to obtain the pathname of an object being
accessed.

To find the pathname of the object, LSM needs the VFS mount point data.
The VFS owns this information, so the question is the best way to convey
it from VFS to relevant LSM hooks. We are agnostic about how to get that
mount point data, but AFAICT saying that LSM can't see the mount point
data at all is equivalent to rejecting pathname based access control
entirely.

>   Retroactively creating the
> full path is at the minimum ugly, and in the worst case can be insecure
> (yes AA has taken many measures to mitigate that insecurity).
>   
The reverse path construction has been criticized for being both broken
and counter-intuitive. Our secure d_path patch fixes the "broken" part,
it now securely reconstructs the path. The counter-intuitive is because
forward construction of the pathname has unexpected costs, making the
retroactive construction more attractive.

> AA folks: deal with the VFS issues that your patchset have in a palatable
> way (which does not include passing NULL when it's inconvenient to
> do otherwise).
John Johansen posted a patch (written by Andreas Gruenbacher) that
introduced a nameidata2 data structure to try to solve the conditional
null passing problem, but it received no comment. A proper fix to this
problem is clearly desirable, but it also is clearly a defect in NFS and
fixing it is a lot of work; why does AA have to stay outside the kernel
until NFS is fixed, when it can easily adapt to the problem until it is
fixed properly?

>   You've already missed an opportunity with Christoph's
> suggestions for changes in NFS.  I know you've considered many alternative
> approaches and consistently hit dead ends.  But please note, if you
> have coded yourself into a corner because of your policy language,
> that's your issue to solve, not ours.  
I think it is a little more fundamental than that. If you are going to
do pathname based access control at all, you need access to sufficient
information to compute the path name. Can we have a discussion about the
best way to do that?

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-25T17:14:11, Pavel Machek <[EMAIL PROTECTED]> wrote:

> Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/
> allows any user to make AA ineffective on large part of systems -- in
> internal discussion. (It is not actually a _bug_, but it is certainly
> unexpected).

Pavel, no, you did not. You _did_ surprise me by misquoting me so badly,
though.

I agreed that actions by not mediated processes can interfere with
mediated processes. That is a given. So you do not give them free access
to a world writable directory.



Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Mon, 25 Jun 2007, Pavel Machek wrote:


Hi!


We've been over the "AA is different" discussion in threads about a
billion times, and at the last kernel summit.  I think Lars and others
have done a pretty good job of describing the problems they are trying
to solve, can we please move on to discussing technical issues around
that?


Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/
allows any user to make AA ineffective on large part of systems -- in
internal discussion. (It is not actually a _bug_, but it is certainly
unexpected).

(Does it surprise you, too? I'm pretty sure it would surprise many users).


no, it doesn't surprise me in the least. AA is controlling access to the 
thing called /etc/shadow, if you grant access to it in other ways you 
bypass the restrictions.


if you follow the ln /etc/shadow /tmp/ with chmod 777 /tmp/shadow the 
system is completely insecure.


this is standard stuff that normal sysadmins expect. it's only people who 
have focused on the label approach who would expect it to be any 
different.



James summarized it nicely:

# The design of the AppArmor is based on _appearing simple_, but at the
# expense of completeness and thus correctness.

If even Lars can be surprised by AAs behaviour, I do not think we can
say "AA is different". I'm afraid that AA is trap for users. It
appears simple, and mostly does what it is told, but does not do _what
user wants_.


I thought it had been made very clear that hard links like this were a 
potential way around the restrictions, which is why controlled tasks are 
not allowed to do arbatrary hard links.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> We've been over the "AA is different" discussion in threads about a
> billion times, and at the last kernel summit.  I think Lars and others
> have done a pretty good job of describing the problems they are trying
> to solve, can we please move on to discussing technical issues around
> that?

Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/
allows any user to make AA ineffective on large part of systems -- in
internal discussion. (It is not actually a _bug_, but it is certainly
unexpected).

(Does it surprise you, too? I'm pretty sure it would surprise many users).

James summarized it nicely:

# The design of the AppArmor is based on _appearing simple_, but at the
# expense of completeness and thus correctness.

If even Lars can be surprised by AAs behaviour, I do not think we can
say "AA is different". I'm afraid that AA is trap for users. It
appears simple, and mostly does what it is told, but does not do _what
user wants_.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> But as someone who doesn't use either SElinux or AA, I really hope
> we can get past the part of the debate where:
> 
> while(1)
> AA) we think we're making users happy with pathname security
> SELINUX) pathname security sucks

(Hopefully I'll not be fired for this. :-)

Yes, we _are_ making users happy with AA.

Questions is if we are making them secure. :-).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Toshiharu Harada]

This thread is amazing.  With so many smart people's precious time,

What are the results?
What are the issues anyway?
Is anyone happy? (I'm not and I assume Chris is not)

Yes, "waste of time" is taking place here, but
it's not for "pathname-based MAC" but for "wrongly posted messages",
I believe.  I'm a relatively new to this ml, let me ask.

Is this ml a place of judge or battle? (not to help or support?)

Nothing is perfect, so we can work to make things to better, right?
I have suggestions:

Let's clarify issues first.
- problems (or limitations) of pathname-based MAC
- advantages of pathname-based MAC
- how can pathname-based MAC supplement label based
(Stephen, James and Kyle, please help)

Let's start the arguments again if we get the issues.
Threads should be definitely separated per issue and
a assigning a chair may help.

Above issues are independent of SELinux. We should not *compare*
SELinux and AA, that can cause a problem. Every software has
shortages that's why we need to work and we can make progress.
For some issues we may need to compare them, in that case
moderators would help.

BTW I have posted a RFC of TOMOYO Linux that is another
pathname-based MAC.
http://lkml.org/lkml/2007/6/13/58
AA and TOMOYO Linux have BoF sessions at OLS2007,
so it would be a great opportunity to *talk* over the issues.

What I want to say is "let's make progress and help each other
to make Linux better".

Thank you,
Toshiharu Harada

Chris Wright wrote:
> * Chris Mason ([EMAIL PROTECTED]) wrote:
>> I'm sure people there will have a different versions of events.  The
>> one part that was discussed was if pathname based security was
>> useful, and a number of the people in the room (outside of 
>> novell) said it was.  Now, it could be that nobody wanted to argue
>> anymore, since most opinions had come out on one list or another by
>> then.  
> 
> Indeed.  The trouble is that's too high level compared with the actual
> implementation details.  AA is stalled because it has failed to get
> VFS support for it's model.  I don't see a nice way out unless it
> changes it's notion of policy language (globbing is the tough one)
> or gets traction to pass dentry/vfsmount all the way down.  Paths are
> completely relevant for security, esp. when considering the parent dir
> and the leaf (as in forward lookup case).  Retroactively creating the
> full path is at the minimum ugly, and in the worst case can be insecure
> (yes AA has taken many measures to mitigate that insecurity).
> 
>> But as someone who doesn't use either SElinux or AA, I really hope
>> we can get past the part of the debate where:
>>
>> while(1)
>> AA) we think we're making users happy with pathname security
>> SELINUX) pathname security sucks
> 
> Yes.  Please.  Both parties are miserably failing the sanity test.
> Doing the same thing over and over and expecting different results.
> 
> AA folks: deal with the VFS issues that your patchset have in a palatable
> way (which does not include passing NULL when it's inconvenient to
> do otherwise).  You've already missed an opportunity with Christoph's
> suggestions for changes in NFS.  I know you've considered many alternative
> approaches and consistently hit dead ends.  But please note, if you
> have coded yourself into a corner because of your policy language,
> that's your issue to solve, not ours.
> 
> SELinux folks: do something useful rather than quibbling over the TCSEC
> definition of MAC and AA's poor taste in marketing literature.  Here's
> some suggestions:
> 
> 1) Make SELinux usable (it's *still* the number one complaint).  While
> this is a bit of a cheap shot, it really is one of the core reasons AA
> advocates exist.
> 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA.
> 3) Write an effective exploit against AA that demonstrates the fundamental
> weakness of the model (better make sure it's not also an issue for
> targetted policy).

-- 
Toshiharu Harada
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Toshiharu Harada]

This thread is amazing.  With so many smart people's precious time,

What are the results?
What are the issues anyway?
Is anyone happy? (I'm not and I assume Chris is not)

Yes, "waste of time" is taking place here, but
it's not for "pathname-based MAC" but for "wrongly posted messages",
I believe.  I'm a relatively new to this ml, let me ask.

Is this ml a place of judge or battle? (not to help or support?)

Nothing is perfect, so we can work to make things to better, right?
I have suggestions:

Let's clarify issues first.
- problems (or limitations) of pathname-based MAC
- advantages of pathname-based MAC
- how can pathname-based MAC supplement label based
(Stephen, James and Kyle, please help)

Let's start the arguments again if we get the issues.
Threads should be definitely separated per issue and
a assigning a chair may help.


Well, I crated a Wiki page. If it helps, please
feel free to use it.  I mean I would like
people to add your issues here.  It's wiki, so
you are welcome to modify everything.

http://tomoyo.sourceforge.jp/wiki-e/?MAC-ISSUES

If ml is better, I have no objections.
I just wanted to help discussion.


Above issues are independent of SELinux. We should not *compare*
SELinux and AA, that can cause a problem. Every software has
shortages that's why we need to work and we can make progress.
For some issues we may need to compare them, in that case
moderators would help.

BTW I have posted a RFC of TOMOYO Linux that is another
pathname-based MAC.
http://lkml.org/lkml/2007/6/13/58
AA and TOMOYO Linux have BoF sessions at OLS2007,
so it would be a great opportunity to *talk* over the issues.

What I want to say is "let's make progress and help each other
to make Linux better".


Cheers,
Toshiharu Harada

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Chris Wright]

* Chris Mason ([EMAIL PROTECTED]) wrote:
> I'm sure people there will have a different versions of events.  The
> one part that was discussed was if pathname based security was
> useful, and a number of the people in the room (outside of 
> novell) said it was.  Now, it could be that nobody wanted to argue
> anymore, since most opinions had come out on one list or another by
> then.  

Indeed.  The trouble is that's too high level compared with the actual
implementation details.  AA is stalled because it has failed to get
VFS support for it's model.  I don't see a nice way out unless it
changes it's notion of policy language (globbing is the tough one)
or gets traction to pass dentry/vfsmount all the way down.  Paths are
completely relevant for security, esp. when considering the parent dir
and the leaf (as in forward lookup case).  Retroactively creating the
full path is at the minimum ugly, and in the worst case can be insecure
(yes AA has taken many measures to mitigate that insecurity).

> But as someone who doesn't use either SElinux or AA, I really hope
> we can get past the part of the debate where:
> 
> while(1)
> AA) we think we're making users happy with pathname security
> SELINUX) pathname security sucks

Yes.  Please.  Both parties are miserably failing the sanity test.
Doing the same thing over and over and expecting different results.

AA folks: deal with the VFS issues that your patchset have in a palatable
way (which does not include passing NULL when it's inconvenient to
do otherwise).  You've already missed an opportunity with Christoph's
suggestions for changes in NFS.  I know you've considered many alternative
approaches and consistently hit dead ends.  But please note, if you
have coded yourself into a corner because of your policy language,
that's your issue to solve, not ours.

SELinux folks: do something useful rather than quibbling over the TCSEC
definition of MAC and AA's poor taste in marketing literature.  Here's
some suggestions:

1) Make SELinux usable (it's *still* the number one complaint).  While
this is a bit of a cheap shot, it really is one of the core reasons AA
advocates exist.
2) Work on a variant of Kyle's suggestion to squash the relevancy of AA.
3) Write an effective exploit against AA that demonstrates the fundamental
weakness of the model (better make sure it's not also an issue for
targetted policy).

thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Fri, 22 Jun 2007, Stephen Smalley wrote:


On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:

On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:

On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:

On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:




And now, yes, I know AA doesn't mediate IPC or networking (yet), but
that's a missing feature, not broken by design.


The incomplete mediation flows from the design, since the pathname-based
mediation doesn't generalize to cover all objects unlike label- or
attribute-based mediation.  And the "use the natural abstraction for
each object type" approach likewise doesn't yield any general model or
anything that you can analyze systematically for data flow.


No the "incomplete" mediation does not flow from the design.  We have
deliberately focused on doing the necessary modifications for pathname
based mediation.  The IPC and network mediation are a wip.


The fact that you have to go back to the drawing board for them is that
you didn't get the abstraction right in the first place.


or it just means that the tool to regulat the network is different from 
the tool to regulate the filesystem.


oh, by the way. that's how the rest of the *nix world works. firewall 
rules apply to networking, filesystem permissions and ACLs apply to the 
filesystem.


this is like climing that the latest improvement to ipsec shouldn't go in 
becouse it down't allow you to handle things the same way that you handle 
temp files or a serial port.



We have never claimed to be using pathname-based mediation IPC or networking.
The "natural abstraction" approach does generize well enough and will
be analyzable.


I think we must have different understandings of the words "generalize"
and "analyzable".  Look, if I want to be able to state properties about
data flow in the system for confidentiality or integrity goals (my
secret data can never leak to unauthorized entities, my critical data
can never be corrupted/tainted by unauthorized entities - directly or
indirectly), then I need to be able to have a common reference point for
my policy.  When my policy is based on different abstractions
(pathnames, IP addresses, window ids, whatever) for different objects,
then I can no longer identify how data can flow throughout the system in
a system-wide way.


if you are doing a system-wide analysis then you are correct.

the AA approach is to start with the exposed items and limit the damage 
that can be done to you.


sysadmins already think in terms of paths and what can access that path 
(directory permissions), AA extends this in a very natural way and doesn't 
require any special tools or extra steps for normal administration. As a 
result sysadmins are far more likely to use this then they are to touch 
anything that requires that they do a full system analysis before they 
start.


another advantage is that since the policies are independant of each other 
it becomes very easy for software to include sample policies with the 
source.



Um, no.  It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.


Actually it can be analyzed and shown.  It is ugly to do and we
currently don't have a tool capable of doing it, but it is possible.


No, it isn't possible when using ambiguous and unstable identifiers for
the subjects and objects, nor when mediation is incomplete.


it is possible to say that without assistance from an outside process the 
process cannot access the files containing your mail.


if there is some other method of accessing the content no filesystem-level 
thing can know about it (for example, if another process is a pop server 
that requires no password). but I don't beleive that SELinux policies as 
distributed by any vendor would prevent this (yes, it would be possible 
for a tailored policy to prevent it, but if the policy is so complex that 
only distro staff should touch it that doesn't matter in real life)


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Fri, 22 Jun 2007, James Morris wrote:


On Fri, 22 Jun 2007, Chris Mason wrote:


But, this is a completely different discussion than if AA is
solving problems in the wild for its intended audience, or if the code
is somehow flawed and breaking other parts of the kernel.


Is its intended audience aware of its limitiations?  Lars has just
acknowledged that it does not implement mandatory access control, for one.

Until people understand these issues, they certainly need to be addressed
in the context of upstream merge.


there are always going to be people who misunderstand things. by this 
logic nothing can ever be merged that can be misused.


at least some of the intended audience (including me) do understand the 
limits and still consider the result useful.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Chris Mason]

On Fri, Jun 22, 2007 at 10:23:03AM -0400, James Morris wrote:
> On Fri, 22 Jun 2007, Chris Mason wrote:
> 
> > But, this is a completely different discussion than if AA is
> > solving problems in the wild for its intended audience, or if the code
> > is somehow flawed and breaking other parts of the kernel.
> 
> Is its intended audience aware of its limitiations?  Lars has just 
> acknowledged that it does not implement mandatory access control, for one.
> 
> Until people understand these issues, they certainly need to be addressed 
> in the context of upstream merge.

It is definitely useful to clearly understand the intended AA use cases
during the merge.

> 
> > We've been over the "AA is different" discussion in threads about a
> > billion times, and at the last kernel summit.
> 
> I don't believe that people at the summit were adequately informed on the 
> issue, and from several accounts I've heard, Stephen Smalley was 
> effectively cut off before he could even get to his second slide.

I'm sure people there will have a different versions of events.  The
one part that was discussed was if pathname based security was
useful, and a number of the people in the room (outside of 
novell) said it was.  Now, it could be that nobody wanted to argue
anymore, since most opinions had come out on one list or another by
then.  

But as someone who doesn't use either SElinux or AA, I really hope
we can get past the part of the debate where:

while(1)
AA) we think we're making users happy with pathname security
SELINUX) pathname security sucks

So, yes Greg got it started and Lars is a well known trouble maker, and
I completely understand if you want to say no thank you to an selinux
based AA ;)  The models are different and it shouldn't be a requirement
that they try to use the same underlying mechanisms.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Casey Schaufler]

--- Stephen Smalley <[EMAIL PROTECTED]> wrote:

 
> Mandatory access control as historically understood has always meant
> system-wide.

Chapter and verse: TCSEC 3.1.1.4 Mandatory Access Control
  "The TCB shall enforce a mandatory access control policy over
   all subjects and storage objects under its control."

Chapter and verse: TCSEC 3.2.1.4 Mandatory Access Control
  "The TCB shall enforce a mandatory access control policy over
   all resources that are directly or indirectly accessible by
   subjects external to the TCB."

The first reference is in the definition of a B1 system, while the
second is for a B2 system. It was made clear to those of us
doing TCSEC evaluations that there is a very real distintion between
these two requirements. In the history that I've been through,
starting in 1987, the B1 requirement has been read to allow for
things that are not storage objects to be uncontrolled while the
B2 requirement does not. If everything is a storage object, which
is the approach everybody took, yes, you're looking at system wide.
If, on the other hand, you were to take a different model approach
and say that networking does not use storage objects you would not
have to account for them under the B1 rules, while you would still
have to for B2. Historically, no one succeeded with B2, and the
mindset of B1 prevailed. So, historically, the understanding was
that it was easier to declare everything a storage object and code
up some MAC for it than it was to provide a security model that
explained networking as it really works. I suggest that if AA wants
to declare that as far as they are concerned sockets, ports, and
packets are none of them storage objects but are instead pregnant
weasels that is their peragotive as system designers and that
a B1 evaluation team would have accepted that, provided sufficient
evidence and explaination of the relevence of pregnant weasels
was provided. It would not have worked at B2, but historically
everyone understood that B2 was out of reach.

Stephen is correct in that historically everyone implemented system
that put everything under MAC, but is not in that it was well
understood that if you could define something as not being a
storage object you didn't have to submit it to MAC. Then as now
it was easier to get people to code MAC than to get them to write
papers about the security properties of pregnant weasels.



Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Fri, 2007-06-22 at 09:22 -0400, Stephen Smalley wrote:
> On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > > Sorry, do you mean the "server" as in the "server system" or as in the
> > > "server daemon"?  For the former, I'd agree - we would want SELinux
> > > policy applied on the server as well as the client to ensure that the
> > > data is being protected consistently throughout and that the server is
> > > not misrepresenting the security guarantees expected by the clients.
> > > Providing an illusion of confinement on each client without any
> > > corresponding protection on the server system would be very prone to
> > > bypass.  For the latter, the kernel can only truly confine application
> > > code, not in-kernel threads, although we can subject the in-kernel nfsd
> > > to permission checking as a robustness check.  We've always noted that
> > > SELinux does depend on the correctness of the kernel.
> > 
> > Oh, you're saying that this threat is out-of-scope? ;-)
> 
> Kernel flaws aren't something we can address (reliably and in general)
> via a kernel mechanism.  Versus a threat that can be addressed by kernel
> mechanism, like providing complete mediation and unambiguous access
> control.  There is a difference.  And we aren't ignoring the kernel
> correctness problem - there is separate work in that space, but it
> requires separate mechanism outside of SELinux itself.
> 
> > Note that here we've already strayed from the focus of the discussion;
> > we're no longer arguing "the implementation is ugly/broken", but you're
> > claiming "doesn't do what I need" - which I'm not disagreeing with. It
> > doesn't do what you want. Which is why you have SELinux, and it's going
> > to stay. Fine.
> > 
> > If we assume that the users who run it do have a need / use case for it
> > which they can't solve differently, we should really get back to the
> > discussion of how those needs can be met or provided by Linux in a
> > feasible way.
> 
> Part of the discussion has been whether those users' needs could be
> solved better via SELinux, whether via improved userspace tools (ala
> seedit possibly with an enhanced restorecond) or via extended kernel
> mechanism (ala named type transitions and some kind of inheritance
> model).  It does however seem like there is a fundamental conflict there
> on renaming behavior; I do not believe that file protections should
> automatically change in the kernel upon rename and should require
> explicit userspace action.  The question though is whether that renaming
> behavior in AA is truly a user requirement or a manufactured (i.e.
> made-up) one, and whether it is truly a runtime requirement or just a
> policy creation time one (the latter being adequately addressed by
> userspace relabeling).

I suppose there is also a question of whether that kind of model
wouldn't be better implemented as an ACL model with implicit
inheritance, e.g. if you specify an ACL on a directory, then all files
accessed via that directory are controlled in accordance with that ACL
unless they have their own more specific ACL, and if you move one of
those files to a different directory, then they automatically pick up
the protection of the new parent.  Doesn't require the kernel to be
matching pathname strings, just walking up the tree to determine the
closest ancestor with an explicit ACL on it.

> 
> If that behavior is truly needed (a point I wouldn't concede), then the
> discussion does reduce down to the right implementation method.  There
> it appears that the primary objection is to regenerating full pathname
> strings and matching them versus some kind of incremental matching
> either during lookup itself or via a reverse match as suggested.  That
> discussion is principally one in which the vfs folks should be engaged,
> not me.
> 
> > > > Your use case mandates complete system-wide mediation, because you want
> > > > full data flow analysis. Mine doesn't.
> > > Then yours isn't mandatory access control, nor is it confinement.  
> > 
> > I apologize for not using the word "confinement" in the way you expect
> > it to be used. I certainly don't want to imply it does do things it
> > doesn't. Keep in mind I'm not a native speaker, so nuances do get lost
> > sometimes; nor do I have long years of experience in the security
> > field. Thanks for clearing this up.
> > 
> > So agreed, it is not confinement nor MAC.
> > 
> > Would it be more appropriate if I used the word "restricts" or
> > "constrains"?
> 
> Yes.  Or simply "controls file accesses and capability usage".
> 
-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 22 Jun 2007, Chris Mason wrote:

> But, this is a completely different discussion than if AA is
> solving problems in the wild for its intended audience, or if the code
> is somehow flawed and breaking other parts of the kernel.

Is its intended audience aware of its limitiations?  Lars has just 
acknowledged that it does not implement mandatory access control, for one.

Until people understand these issues, they certainly need to be addressed 
in the context of upstream merge.

> We've been over the "AA is different" discussion in threads about a
> billion times, and at the last kernel summit.

I don't believe that people at the summit were adequately informed on the 
issue, and from several accounts I've heard, Stephen Smalley was 
effectively cut off before he could even get to his second slide.

> I think Lars and others have done a pretty good job of describing the 
> problems they are trying to solve, can we please move on to discussing 
> technical issues around that?

Keep in mind that this current thread arose from Greg KH asking about 
whether AppArmor could effectively be implemented via SELinux and 
userspace labeling.

Some of us took the time to perform analysis and then provide feedback on 
this, in good faith.

The underlying issues only came up again in response to an inflammatory 
post by Lars.  If you want to avoid discussions of AppArmor's design, then 
I suggest taking it up with those who initiate them.



- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Chris Mason]

On Fri, Jun 22, 2007 at 09:48:12AM -0400, James Morris wrote:
> On Fri, 22 Jun 2007, Chris Mason wrote:
> 
> > > The validity or otherwise of pathname access control is not being 
> > > discussed here.
> > > 
> > > The point is that the pathname model does not generalize, and that 
> > > AppArmor's inability to provide adequate coverage of the system is a 
> > > design issue arising from this.
> > 
> > I'm sorry, but I don't see where in the paragraphs above you aren't
> > making a general argument against the pathname model.
> 
> There are two distinct concepts here.
> 
> A. Pathname labeling - applying access control to pathnames to objects, 
> rather than labeling the objects themselves.
> 
> Think of this as, say, securing your house by putting a gate in the street 
> in front of the house, regardless of how many other possible paths there 
> are to the house via other streets, adjoining properties etc.
> 
> Pathname labeling and mediation is simply mediating a well-known path to 
> the object.  In this analogy, object labeling would instead ensure that 
> all of the accessible doors, windows and other entrances of the house were 
> locked, so that someone trying to break in from the rear alley would 
> not get in simply by bypassing the front gate and opening any door.
> 
> What you do with AppArmor, instead of addressing the problem, is just 
> redefine the environment along the lines of "set your house into a rock 
> wall so there is only one path to it".
> 
> 
> B. Pathname access control as a general abstraction for OS security.
> 
> Which is what was being discussed above, in response to a question from 
> Lars about technical issues, and that this _model_ doesn't generalize to 
> the rest of the OS, regardless of whether you think the mechanism of 
> pathname labeling itself is appropriate or not.

I'm sorry, but I don't see where in the paragraphs above you aren't
making a general argument against the pathname model.  I'm not trying to
get into that discussion (I'm smart enough to know I'm far too stupid to
hold my own there).

I do understand that AA is different from selinux, and that you
have valid points about the level and type of protection that AA offers.

But, this is a completely different discussion than if AA is
solving problems in the wild for its intended audience, or if the code
is somehow flawed and breaking other parts of the kernel.

We've been over the "AA is different" discussion in threads about a
billion times, and at the last kernel summit.  I think Lars and others
have done a pretty good job of describing the problems they are trying
to solve, can we please move on to discussing technical issues around
that?

-chris



-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 22 Jun 2007, Chris Mason wrote:

> > The validity or otherwise of pathname access control is not being 
> > discussed here.
> > 
> > The point is that the pathname model does not generalize, and that 
> > AppArmor's inability to provide adequate coverage of the system is a 
> > design issue arising from this.
> 
> I'm sorry, but I don't see where in the paragraphs above you aren't
> making a general argument against the pathname model.

There are two distinct concepts here.

A. Pathname labeling - applying access control to pathnames to objects, 
rather than labeling the objects themselves.

Think of this as, say, securing your house by putting a gate in the street 
in front of the house, regardless of how many other possible paths there 
are to the house via other streets, adjoining properties etc.

Pathname labeling and mediation is simply mediating a well-known path to 
the object.  In this analogy, object labeling would instead ensure that 
all of the accessible doors, windows and other entrances of the house were 
locked, so that someone trying to break in from the rear alley would 
not get in simply by bypassing the front gate and opening any door.

What you do with AppArmor, instead of addressing the problem, is just 
redefine the environment along the lines of "set your house into a rock 
wall so there is only one path to it".


B. Pathname access control as a general abstraction for OS security.

Which is what was being discussed above, in response to a question from 
Lars about technical issues, and that this _model_ doesn't generalize to 
the rest of the OS, regardless of whether you think the mechanism of 
pathname labeling itself is appropriate or not.

In any case, clarifying such a distinction should not obscure the central 
issue, which is: AppArmor's design is broken.

General users, many kernel developers, and even security researchers who 
have not yet looked under the covers [1], are probably unaware that the 
confinement claims being made about AppArmor's confinement capabilities 
are simply not possible with either its model or implementation.

To quote from:

http://www.novell.com/linux/security/apparmor/

  "AppArmor gives you network application security via mandatory access 
   control for programs, protecting against the exploitation of software 
   flaws and compromised systems. AppArmor includes everything you need to 
   provide effective containment for programs (including those that run as 
   root) to thwart attempted exploits and even zero-day attacks."

This is not accurate in any sense of the term containment of mandatory 
access control that I've previously encountered.

The fact that it doesn't work as expected does not arise simply from 
missing features or being "different".  It arises from the design of the 
system, which uses a pathname abstraction, where, even if we agree to 
ignore issue (1) above, still does not work, because only filesystem 
interactions are mediated.

AppArmor policy does not reflect the behavior of the system.

The "simple" policy that users can so effortlessly manipulate is simple 
because it is wrong, and deliberately so.

The design of the AppArmor is based on _appearing simple_, but at the 
expense of completeness and thus correctness.


[1] http://lkml.org/lkml/2007/4/19/357

  "My gosh, you're right.  What the heck?  With all due respect to the
   developers of AppArmor, I can't help thinking that that's pretty lame.
   I think this raises substantial questions about the value of AppArmor.
   What is the point of having a jail if it leaves gaping holes that
   malicious code could use to escape?

   And why isn't this documented clearly, with the implications fully
   explained?"  - David Wagner, http://www.cs.berkeley.edu/~daw/
 

Indeed.



- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > Sorry, do you mean the "server" as in the "server system" or as in the
> > "server daemon"?  For the former, I'd agree - we would want SELinux
> > policy applied on the server as well as the client to ensure that the
> > data is being protected consistently throughout and that the server is
> > not misrepresenting the security guarantees expected by the clients.
> > Providing an illusion of confinement on each client without any
> > corresponding protection on the server system would be very prone to
> > bypass.  For the latter, the kernel can only truly confine application
> > code, not in-kernel threads, although we can subject the in-kernel nfsd
> > to permission checking as a robustness check.  We've always noted that
> > SELinux does depend on the correctness of the kernel.
> 
> Oh, you're saying that this threat is out-of-scope? ;-)

Kernel flaws aren't something we can address (reliably and in general)
via a kernel mechanism.  Versus a threat that can be addressed by kernel
mechanism, like providing complete mediation and unambiguous access
control.  There is a difference.  And we aren't ignoring the kernel
correctness problem - there is separate work in that space, but it
requires separate mechanism outside of SELinux itself.

> Note that here we've already strayed from the focus of the discussion;
> we're no longer arguing "the implementation is ugly/broken", but you're
> claiming "doesn't do what I need" - which I'm not disagreeing with. It
> doesn't do what you want. Which is why you have SELinux, and it's going
> to stay. Fine.
> 
> If we assume that the users who run it do have a need / use case for it
> which they can't solve differently, we should really get back to the
> discussion of how those needs can be met or provided by Linux in a
> feasible way.

Part of the discussion has been whether those users' needs could be
solved better via SELinux, whether via improved userspace tools (ala
seedit possibly with an enhanced restorecond) or via extended kernel
mechanism (ala named type transitions and some kind of inheritance
model).  It does however seem like there is a fundamental conflict there
on renaming behavior; I do not believe that file protections should
automatically change in the kernel upon rename and should require
explicit userspace action.  The question though is whether that renaming
behavior in AA is truly a user requirement or a manufactured (i.e.
made-up) one, and whether it is truly a runtime requirement or just a
policy creation time one (the latter being adequately addressed by
userspace relabeling).

If that behavior is truly needed (a point I wouldn't concede), then the
discussion does reduce down to the right implementation method.  There
it appears that the primary objection is to regenerating full pathname
strings and matching them versus some kind of incremental matching
either during lookup itself or via a reverse match as suggested.  That
discussion is principally one in which the vfs folks should be engaged,
not me.

> > > Your use case mandates complete system-wide mediation, because you want
> > > full data flow analysis. Mine doesn't.
> > Then yours isn't mandatory access control, nor is it confinement.  
> 
> I apologize for not using the word "confinement" in the way you expect
> it to be used. I certainly don't want to imply it does do things it
> doesn't. Keep in mind I'm not a native speaker, so nuances do get lost
> sometimes; nor do I have long years of experience in the security
> field. Thanks for clearing this up.
> 
> So agreed, it is not confinement nor MAC.
> 
> Would it be more appropriate if I used the word "restricts" or
> "constrains"?

Yes.  Or simply "controls file accesses and capability usage".

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote:

> The issue arises even for a collection of collaborating confined
> processes with different profiles, and the collaboration may be
> intentional or unintentional (in the latter case, one of the confined
> processes may be taking advantage of known behavior of another process
> and shared access by both to some resource in order to induce a
> particular behavior in that process).

Point taken; the point remains is that you need at least several
(intentionally or not) cooperating processes. The chances of this are
significantly lower than a single process exploit.

> And remember that confinement isn't just about limiting untrusted
> processes but also about protecting trusted processes; limiting the
> inputs and outputs of a trusted process can be just as important to
> preventing exploitation.

True. It'd appear that if you want that, you'd specify the AA profile so
that it doesn't include directories/files writable by untrusted
processes.

> Sorry, do you mean the "server" as in the "server system" or as in the
> "server daemon"?  For the former, I'd agree - we would want SELinux
> policy applied on the server as well as the client to ensure that the
> data is being protected consistently throughout and that the server is
> not misrepresenting the security guarantees expected by the clients.
> Providing an illusion of confinement on each client without any
> corresponding protection on the server system would be very prone to
> bypass.  For the latter, the kernel can only truly confine application
> code, not in-kernel threads, although we can subject the in-kernel nfsd
> to permission checking as a robustness check.  We've always noted that
> SELinux does depend on the correctness of the kernel.

Oh, you're saying that this threat is out-of-scope? ;-)

> Every time we've noted an issue with AA, the answer has been that it is
> out of scope.  Yet the public documentation for AA misrepresents the
> situation and its comparisons with SELinux conveniently ignore its
> limitations.

I'm sorry. Again, I'm not responsible for marketing comparisons made by
anyone else, nor do I think they should apply to this discussion where
we're discussing the merits of what AA actually _does_; not what
someone's marketing claims it does - otherwise I'll go dig out marketing
claims about SELinux too ;-)

And, coming at it from that direction, I feel it does something useful.

Note that here we've already strayed from the focus of the discussion;
we're no longer arguing "the implementation is ugly/broken", but you're
claiming "doesn't do what I need" - which I'm not disagreeing with. It
doesn't do what you want. Which is why you have SELinux, and it's going
to stay. Fine.

If we assume that the users who run it do have a need / use case for it
which they can't solve differently, we should really get back to the
discussion of how those needs can be met or provided by Linux in a
feasible way.

> > Your use case mandates complete system-wide mediation, because you want
> > full data flow analysis. Mine doesn't.
> Then yours isn't mandatory access control, nor is it confinement.  

I apologize for not using the word "confinement" in the way you expect
it to be used. I certainly don't want to imply it does do things it
doesn't. Keep in mind I'm not a native speaker, so nuances do get lost
sometimes; nor do I have long years of experience in the security
field. Thanks for clearing this up.

So agreed, it is not confinement nor MAC.

Would it be more appropriate if I used the word "restricts" or
"constrains"?


Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Fri, 2007-06-22 at 14:42 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T07:53:47, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> 
> > > No the "incomplete" mediation does not flow from the design.  We have
> > > deliberately focused on doing the necessary modifications for pathname
> > > based mediation.  The IPC and network mediation are a wip.
> > The fact that you have to go back to the drawing board for them is that
> > you didn't get the abstraction right in the first place.
> 
> That's an interesting claim, however I don't think it holds. AA was
> designed to mediate file access in a form which is intuitive to admins.
> 
> It's to be expected that it doesn't directly apply to mediating other
> forms of access.
> 
> > I think we must have different understandings of the words "generalize"
> > and "analyzable".  Look, if I want to be able to state properties about
> > data flow in the system for confidentiality or integrity goals (my
> > secret data can never leak to unauthorized entities, my critical data
> > can never be corrupted/tainted by unauthorized entities - directly or
> > indirectly),
> 
> I seem to think that this is not what AA is trying to do, so evaluating
> it in that context doesn't seem useful. It's like saying a screw driver
> isn't a hammer, so it is useless because you have a nail.

Again, in that case, please remove all uses of the terms "mandatory
access control", "confinement" and "integrity protection" from AA
documentation and code.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Fri, 2007-06-22 at 13:37 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T07:19:39, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> 
> > > > Or can access the data under a different path to which their profile
> > > > does give them access, whether in its final destination or in some
> > > > temporary file processed along the way.
> > > Well, yes. That is intentional.
> > > 
> > > Your point is?
> > 
> > It may very well be unintentional access, especially when taking into
> > account wildcards in profiles and user-writable directories.
> 
> Again, you're saying that AA is not confining unconfined processes.
> That's a given. If unconfined processes assist confined processes in
> breeching their confinement, yes, that is not mediated.

The issue arises even for a collection of collaborating confined
processes with different profiles, and the collaboration may be
intentional or unintentional (in the latter case, one of the confined
processes may be taking advantage of known behavior of another process
and shared access by both to some resource in order to induce a
particular behavior in that process).

And remember that confinement isn't just about limiting untrusted
processes but also about protecting trusted processes; limiting the
inputs and outputs of a trusted process can be just as important to
preventing exploitation.

> You're basically saying that anything but system-wide mandatory access
> control is pointless.

Mandatory access control as historically understood has always meant
system-wide.  As well as always being based on the security properties
of the data (so that global and persistent protection of the data is
possible).  You can't actually use the terms 'mandatory access control'
or 'confinement' for AppArmor unless you redefine them.

> If you want to go down that route, what is your reply to me saying that
> SELinux cannot mediate NFS mounts - if the server is not confined using
> SELinux as well? The argument is really, really moot and pointless. Yes,
> unconfined actions can affect confined processes. 

Sorry, do you mean the "server" as in the "server system" or as in the
"server daemon"?  For the former, I'd agree - we would want SELinux
policy applied on the server as well as the client to ensure that the
data is being protected consistently throughout and that the server is
not misrepresenting the security guarantees expected by the clients.
Providing an illusion of confinement on each client without any
corresponding protection on the server system would be very prone to
bypass.  For the latter, the kernel can only truly confine application
code, not in-kernel threads, although we can subject the in-kernel nfsd
to permission checking as a robustness check.  We've always noted that
SELinux does depend on the correctness of the kernel.

> > > That is an interesting argument, but not what we're discussing here.
> > > We're arguing filesystem access mediation.
> > IOW, anything that AA cannot protect against is "out of scope".  An easy
> > escape from any criticism.
> 
> I'm quite sure that this reply is not AA specific as you try to make it
> appear.

Every time we've noted an issue with AA, the answer has been that it is
out of scope.  Yet the public documentation for AA misrepresents the
situation and its comparisons with SELinux conveniently ignore its
limitations.

> > > Yes. Your use case is different than mine.
> > My use case is being able to protect data reliably.  Yours?
> 
> I want to restrict certain possibly untrusted applications and
> network-facing services from accessing certain file patterns, because as
> a user and admin, that's the mindset I'm used to. I might be interested
> in mediating other channels too, but the files are what I really care
> about. I'm inclined to trust the other processes.
> 
> Your use case mandates complete system-wide mediation, because you want
> full data flow analysis. Mine doesn't.

Then yours isn't mandatory access control, nor is it confinement.  

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-22T07:53:47, Stephen Smalley <[EMAIL PROTECTED]> wrote:

> > No the "incomplete" mediation does not flow from the design.  We have
> > deliberately focused on doing the necessary modifications for pathname
> > based mediation.  The IPC and network mediation are a wip.
> The fact that you have to go back to the drawing board for them is that
> you didn't get the abstraction right in the first place.

That's an interesting claim, however I don't think it holds. AA was
designed to mediate file access in a form which is intuitive to admins.

It's to be expected that it doesn't directly apply to mediating other
forms of access.

> I think we must have different understandings of the words "generalize"
> and "analyzable".  Look, if I want to be able to state properties about
> data flow in the system for confidentiality or integrity goals (my
> secret data can never leak to unauthorized entities, my critical data
> can never be corrupted/tainted by unauthorized entities - directly or
> indirectly),

I seem to think that this is not what AA is trying to do, so evaluating
it in that context doesn't seem useful. It's like saying a screw driver
isn't a hammer, so it is useless because you have a nail.


Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Chris Mason]

On Thu, Jun 21, 2007 at 09:06:40PM -0400, James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:
> 
> > > The incomplete mediation flows from the design, since the pathname-based
> > > mediation doesn't generalize to cover all objects unlike label- or
> > > attribute-based mediation.  And the "use the natural abstraction for
> > > each object type" approach likewise doesn't yield any general model or
> > > anything that you can analyze systematically for data flow.
> > 
> > This feels quite a lot like a repeat of the discussion at the kernel
> > summit.  There are valid uses for path based security, and if they don't
> > fit your needs, please don't use them.  But, path based semantics alone
> > are not a valid reason to shut out AA.
> 
> The validity or otherwise of pathname access control is not being 
> discussed here.
> 
> The point is that the pathname model does not generalize, and that 
> AppArmor's inability to provide adequate coverage of the system is a 
> design issue arising from this.

I'm sorry, but I don't see where in the paragraphs above you aren't
making a general argument against the pathname model.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Thu, 2007-06-21 at 22:17 -0600, Crispin Cowan wrote:
> James Morris wrote:
> > On Thu, 21 Jun 2007, Chris Mason wrote:  
> >>> The incomplete mediation flows from the design, since the pathname-based
> >>> mediation doesn't generalize to cover all objects unlike label- or
> >>> attribute-based mediation.  And the "use the natural abstraction for
> >>> each object type" approach likewise doesn't yield any general model or
> >>> anything that you can analyze systematically for data flow.
> >>>   
> >> This feels quite a lot like a repeat of the discussion at the kernel
> >> summit.  There are valid uses for path based security, and if they don't
> >> fit your needs, please don't use them.  But, path based semantics alone
> >> are not a valid reason to shut out AA.
> >> 
> > The validity or otherwise of pathname access control is not being 
> > discussed here.
> >
> > The point is that the pathname model does not generalize, and that 
> > AppArmor's inability to provide adequate coverage of the system is a 
> > design issue arising from this.
> >   
> The above two paragraphs appear to contradict each other.
> 
> > Recall that the question asked by Lars was whether there were any 
> > outstanding technical issues relating to AppArmor.
> >
> > AppArmor does not and can not provide the level of confinement claimed by 
> > the documentation, and its policy does not reflect its actual confinement 
> > properties.  That's kind of a technical issue, right?
> >   
> So if the document said "confinement with respect to direct file access
> and POSIX.1e capabilities" and that list got extended as AA got new
> confinement features, would that address your issue?

That would certainly help, although one might quibble with the use of
the word "confinement" at all wrt AppArmor (it has a long-established
technical meaning that implies information flow control, and that goes
beyond even complete mediation - it requires global and persistent
protection of the data based on its properties, which requires stable
and unambiguous identifiers).

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
> On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> > On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> > > 
> > 
> > > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > > that's a missing feature, not broken by design.
> > 
> > The incomplete mediation flows from the design, since the pathname-based
> > mediation doesn't generalize to cover all objects unlike label- or
> > attribute-based mediation.  And the "use the natural abstraction for
> > each object type" approach likewise doesn't yield any general model or
> > anything that you can analyze systematically for data flow.
> > 
> No the "incomplete" mediation does not flow from the design.  We have
> deliberately focused on doing the necessary modifications for pathname
> based mediation.  The IPC and network mediation are a wip.

The fact that you have to go back to the drawing board for them is that
you didn't get the abstraction right in the first place.

> We have never claimed to be using pathname-based mediation IPC or networking.
> The "natural abstraction" approach does generize well enough and will
> be analyzable.

I think we must have different understandings of the words "generalize"
and "analyzable".  Look, if I want to be able to state properties about
data flow in the system for confidentiality or integrity goals (my
secret data can never leak to unauthorized entities, my critical data
can never be corrupted/tainted by unauthorized entities - directly or
indirectly), then I need to be able to have a common reference point for
my policy.  When my policy is based on different abstractions
(pathnames, IP addresses, window ids, whatever) for different objects,
then I can no longer identify how data can flow throughout the system in
a system-wide way. 

> > Um, no.  It might not be able to directly open files via that path, but
> > showing that it can never read or write your mail is a rather different
> > matter.
> > 
> Actually it can be analyzed and shown.  It is ugly to do and we
> currently don't have a tool capable of doing it, but it is possible.

No, it isn't possible when using ambiguous and unstable identifiers for
the subjects and objects, nor when mediation is incomplete.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Fri, 2007-06-22 at 21:34 +1000, Neil Brown wrote:
> On Friday June 22, [EMAIL PROTECTED] wrote:
> > > 
> > > Yes. Your use case is different than mine.
> > 
> > My use case is being able to protect data reliably.  Yours?
> 
> Saying "protect data" is nearly meaningless without a threat model.
> I bet you don't try to protect data from a direct nuclear hit, or a
> court order.
> 
> 
> AA has a fairly clear threat model.  It involves a flaw in a
> program being used by an external agent to cause it to use
> privileges it would not normally exercise to subvert privacy or
> integrity.
> I think this model matches a lot of real threats that real sysadmins
> have real concerns about.  I believe that the design of AA addresses
> this model quite well.
>  
> 
> What is your threat model?  Maybe it is just different.

The threat "model" you describe above is a subset of what SELinux
addresses.  And our argument is that AA does not meet that model well,
because it relies upon ambiguous and unstable identifiers for subjects
and objects (a violation of the fundamental requirements for access
control) and because it provides very incomplete mediation.

>From http://www.nsa.gov/selinux/info/faq.cfm:
The Security-enhanced Linux's new features are designed to enforce the
separation of information based on confidentiality and integrity
requirements. They are designed for preventing processes from reading
data and programs, tampering with data and programs, bypassing
application security mechanisms, executing untrustworthy programs, or
interfering with other processes in violation of the system security
policy. They also help to confine the potential damage that can be
caused by malicious or flawed programs. They should also be useful for
enabling a single system to be used by users with differing security
authorizations to access multiple kinds of information with differing
security requirements without compromising those security requirements.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-22T07:19:39, Stephen Smalley <[EMAIL PROTECTED]> wrote:

> > > Or can access the data under a different path to which their profile
> > > does give them access, whether in its final destination or in some
> > > temporary file processed along the way.
> > Well, yes. That is intentional.
> > 
> > Your point is?
> 
> It may very well be unintentional access, especially when taking into
> account wildcards in profiles and user-writable directories.

Again, you're saying that AA is not confining unconfined processes.
That's a given. If unconfined processes assist confined processes in
breeching their confinement, yes, that is not mediated.

You're basically saying that anything but system-wide mandatory access
control is pointless.

If you want to go down that route, what is your reply to me saying that
SELinux cannot mediate NFS mounts - if the server is not confined using
SELinux as well? The argument is really, really moot and pointless. Yes,
unconfined actions can affect confined processes. 

That's generally true for _any_ security system.

> > That is an interesting argument, but not what we're discussing here.
> > We're arguing filesystem access mediation.
> IOW, anything that AA cannot protect against is "out of scope".  An easy
> escape from any criticism.

I'm quite sure that this reply is not AA specific as you try to make it
appear.

> > Yes. Your use case is different than mine.
> My use case is being able to protect data reliably.  Yours?

I want to restrict certain possibly untrusted applications and
network-facing services from accessing certain file patterns, because as
a user and admin, that's the mindset I'm used to. I might be interested
in mediating other channels too, but the files are what I really care
about. I'm inclined to trust the other processes.

Your use case mandates complete system-wide mediation, because you want
full data flow analysis. Mine doesn't.



Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Neil Brown]

On Friday June 22, [EMAIL PROTECTED] wrote:
> > 
> > Yes. Your use case is different than mine.
> 
> My use case is being able to protect data reliably.  Yours?

Saying "protect data" is nearly meaningless without a threat model.
I bet you don't try to protect data from a direct nuclear hit, or a
court order.


AA has a fairly clear threat model.  It involves a flaw in a
program being used by an external agent to cause it to use
privileges it would not normally exercise to subvert privacy or
integrity.
I think this model matches a lot of real threats that real sysadmins
have real concerns about.  I believe that the design of AA addresses
this model quite well. 

What is your threat model?  Maybe it is just different.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Thu, 2007-06-21 at 23:17 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> 
> > Or can access the data under a different path to which their profile
> > does give them access, whether in its final destination or in some
> > temporary file processed along the way.
> 
> Well, yes. That is intentional.
> 
> Your point is?

It may very well be unintentional access, especially when taking into
account wildcards in profiles and user-writable directories.

> > The emphasis on never modifying applications for security in AA likewise
> > has an adverse impact here, as you will ultimately have to deal with
> > application mediation of access to their own objects and operations not
> > directly visible to the kernel (as we have already done in SELinux for
> > D-BUS and others and are doing for X).  Otherwise, your "protection" of
> > desktop applications is easily subverted.
> 
> That is an interesting argument, but not what we're discussing here.
> We're arguing filesystem access mediation.

IOW, anything that AA cannot protect against is "out of scope".  An easy
escape from any criticism.

> > Um, no.  It might not be able to directly open files via that path, but
> > showing that it can never read or write your mail is a rather different
> > matter.
> 
> Yes. Your use case is different than mine.

My use case is being able to protect data reliably.  Yours?

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-21T23:45:36, Joshua Brindle <[EMAIL PROTECTED]> wrote:

> >remember, the policies define a white-list
> 
> Except for unconfined processes.

The argument that AA doesn't mediate what it is not configured to
mediate is correct, yes, but I don't think that's a valid _design_ issue
with AA.

> Or through IPC or the network, that is the point, filesystem only 
> coverage doesn't cut it; there is no way to say the browser can't access 
> the users mail in AA, and there never will be.

We have a variety of filtering mechanisms which are specific to a
domain. iptables filters networking only; file permissions filter file
access only. This argument is not really strong.


If you're now arguing the "spirit of Unix", I can turn your argument
around too: the Unix spirit is to have smallish dedicated tools. If AA
is dedicated to mediating file access, isn't that nice!

AA _could_ be extended to mediate network access and IPC (and this is
WIP). If we had tcpfs and ipcfs - you know, everything is a filesystem,
the Linux spirit! ;-) - AA could mediate them as well.


However, we're discussing the way it mediates file accesses here,
for which it appears useful and capable of functionality which SELinux's
approach cannot provide.


Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Andreas Gruenbacher]

On Saturday 16 June 2007 02:20, Pavel Machek wrote:
> Ok, so mv gets slower for big trees... and open() gets faster for deep
> trees. Previously, open in current directory was one atomic read of
> directory entry, now it has to read directory, and its parent, and its
> parent parent, and its...
>
> (Or am I wrong and getting full path does not need to bring anything
> in, not even in cache-cold case?)

You are wrong, indeed. The dentries in the dcache are connected to the dcache 
through their parent dentry pointers, which means that the parent dentries 
are always in memory, too. No I/O is involved for walking up dentry trees.

(Caveat: nfsd does allow disconnected dentries. It does not make sense to try 
confining an in-kernel daemon though, an no user process can ever access a 
dentry before it gets connected (lookup does that), so this difference is 
irrelevant here.)
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[John Johansen]

On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> > 
> 
> > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > that's a missing feature, not broken by design.
> 
> The incomplete mediation flows from the design, since the pathname-based
> mediation doesn't generalize to cover all objects unlike label- or
> attribute-based mediation.  And the "use the natural abstraction for
> each object type" approach likewise doesn't yield any general model or
> anything that you can analyze systematically for data flow.
> 
No the "incomplete" mediation does not flow from the design.  We have
deliberately focused on doing the necessary modifications for pathname
based mediation.  The IPC and network mediation are a wip.

We have never claimed to be using pathname-based mediation IPC or networking.
The "natural abstraction" approach does generize well enough and will
be analyzable.

> The emphasis on never modifying applications for security in AA likewise
> has an adverse impact here, as you will ultimately have to deal with
> application mediation of access to their own objects and operations not
> directly visible to the kernel (as we have already done in SELinux for
> D-BUS and others and are doing for X).  Otherwise, your "protection" of
> desktop applications is easily subverted.
> 
yes of course, we realize that dbus and X must be trusted applications,
this to will happen.  But it will happen piece meal, something about
releasing early and often comes to mind.

> > > You might define this as a non-technical issue, but the fact that 
> > > AppArmor 
> > > simply does not and can not work is a fairly significant consideration, I 
> > > would imagine.
> > 
> > If I restrict my Mozilla to not access my on-disk mail folder, it can't
> > get there. (Barring bugs in programs which Mozilla is allowed to run
> > unconfined, sure.)
> 
> Um, no.  It might not be able to directly open files via that path, but
> showing that it can never read or write your mail is a rather different
> matter.
> 
Actually it can be analyzed and shown.  It is ugly to do and we
currently don't have a tool capable of doing it, but it is possible.


pgpC22P7rGCbZ.pgp
Description: PGP signature

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[John Johansen]

On Thu, Jun 21, 2007 at 09:06:40PM -0400, James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:
> 
> > > The incomplete mediation flows from the design, since the pathname-based
> > > mediation doesn't generalize to cover all objects unlike label- or
> > > attribute-based mediation.  And the "use the natural abstraction for
> > > each object type" approach likewise doesn't yield any general model or
> > > anything that you can analyze systematically for data flow.
> > 
> > This feels quite a lot like a repeat of the discussion at the kernel
> > summit.  There are valid uses for path based security, and if they don't
> > fit your needs, please don't use them.  But, path based semantics alone
> > are not a valid reason to shut out AA.
> 
> The validity or otherwise of pathname access control is not being 
> discussed here.
> 
> The point is that the pathname model does not generalize, and that 
> AppArmor's inability to provide adequate coverage of the system is a 
> design issue arising from this.
> 
As we have previously stated we are not using pathnames for IPC.  The
use of pathnames for file access mediation is not a design issue that in
anyway prevents us from extending AppArmor to mediate IPC or networking.

The current focus is making the revision necessary for AppArmor's file
mediation at which point we can focus on finishing of the network
and IPC support.

> Recall that the question asked by Lars was whether there were any 
> outstanding technical issues relating to AppArmor.
> 
> AppArmor does not and can not provide the level of confinement claimed by 
> the documentation, and its policy does not reflect its actual confinement 
> properties.  That's kind of a technical issue, right?
> 
AppArmor currently controls file and capabilities, which was explicitly
stated in the documentation submitted with the patches.  And it has
been posted before that network and IPC mediation are a wip.




pgpa39172kAUO.pgp
Description: PGP signature

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Crispin Cowan]

James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:  
>>> The incomplete mediation flows from the design, since the pathname-based
>>> mediation doesn't generalize to cover all objects unlike label- or
>>> attribute-based mediation.  And the "use the natural abstraction for
>>> each object type" approach likewise doesn't yield any general model or
>>> anything that you can analyze systematically for data flow.
>>>   
>> This feels quite a lot like a repeat of the discussion at the kernel
>> summit.  There are valid uses for path based security, and if they don't
>> fit your needs, please don't use them.  But, path based semantics alone
>> are not a valid reason to shut out AA.
>> 
> The validity or otherwise of pathname access control is not being 
> discussed here.
>
> The point is that the pathname model does not generalize, and that 
> AppArmor's inability to provide adequate coverage of the system is a 
> design issue arising from this.
>   
The above two paragraphs appear to contradict each other.

> Recall that the question asked by Lars was whether there were any 
> outstanding technical issues relating to AppArmor.
>
> AppArmor does not and can not provide the level of confinement claimed by 
> the documentation, and its policy does not reflect its actual confinement 
> properties.  That's kind of a technical issue, right?
>   
So if the document said "confinement with respect to direct file access
and POSIX.1e capabilities" and that list got extended as AA got new
confinement features, would that address your issue?

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor


-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Thu, 21 Jun 2007, Joshua Brindle wrote:


[EMAIL PROTECTED] wrote:

 On Thu, 21 Jun 2007, Joshua Brindle wrote:

>  Lars Marowsky-Bree wrote:
> >   On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >   
> > 
> > 
> > >   Um, no.  It might not be able to directly open files via that 
> >  path, but
> > >   showing that it can never read or write your mail is a rather 
> >  different

> > >   matter.
> > > 
> >   Yes. Your use case is different than mine.
> > 
> 
>  So.. your use case is what? If an AA user asked you to protect his mail 
>  from his browser I'm sure you'd truthfully answer "no, we can't do that 
>  but we can protect the path to your mail from your browser".. I think 
>  not. One need only look at the wonderful marketing literature for AA to 
>  see what you are telling people it can do, and your above statement 
>  isn't consistent with that, sorry.


 remember, the policies define a white-list



Except for unconfined processes.


correct, but we are talking about what a confined process can get to 
without assistance from an unconfined process.



 so if a hacker wants to have mozilla access the mail files he needs to get
 some other process on the sysstem to create a link or move a file to a
 path that mozilla does have access to. until that is done there is no way
 for mozilla to access the mail through the filesystem.

 other programs could be run that would give mozilla access to the mail
 contents, but it would be through some other path that the policy
 permitted mozilla accessing in the first place.

Or through IPC or the network, that is the point, filesystem only coverage 
doesn't cut it; there is no way to say the browser can't access the users 
mail in AA, and there never will be.


AA can be extended to cover these things in the future.

remember 'release early release often'?
how about 'perfect is the enemy of good enoug'?

at this point they're trying to get the initial implementation in so that 
people can start takeing advantage of it. As a side effect the cost of 
maintaining it will decrease, and they can put effort into planning future 
enhancements.


besides, as far as the network communication goes, doesn't netfilter now 
have a way to make rules for specific processes? if they don't then it 
could be added, but the details of the implementation would probably be 
very different from the current AA file controls.


how does delaying the acceptance of the current implementation encourage 
the additional features being added?


but to answer your two comments.

how does mozilla access your mail over the network without first capturing 
your password from somewhere?


as far as IPC goes, unix sockets are unavailable (AA as-is will control 
them), so you must be talking about signals or shared memory as the IPC 
mechanisms that mozilla would use to access your mail.


please explain to me what mail client you are useing that exposes your 
mail via these mechinsms.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

[EMAIL PROTECTED] wrote:

On Thu, 21 Jun 2007, Joshua Brindle wrote:


Lars Marowsky-Bree wrote:

 On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
 


>  Um, no.  It might not be able to directly open files via that 
path, but
>  showing that it can never read or write your mail is a rather 
different

>  matter.
>
 Yes. Your use case is different than mine.



So.. your use case is what? If an AA user asked you to protect his 
mail from his browser I'm sure you'd truthfully answer "no, we can't 
do that but we can protect the path to your mail from your browser".. 
I think not. One need only look at the wonderful marketing literature 
for AA to see what you are telling people it can do, and your above 
statement isn't consistent with that, sorry.


remember, the policies define a white-list



Except for unconfined processes.

so if a hacker wants to have mozilla access the mail files he needs to 
get some other process on the sysstem to create a link or move a file 
to a path that mozilla does have access to. until that is done there 
is no way for mozilla to access the mail through the filesystem.


other programs could be run that would give mozilla access to the mail 
contents, but it would be through some other path that the policy 
permitted mozilla accessing in the first place.


Or through IPC or the network, that is the point, filesystem only 
coverage doesn't cut it; there is no way to say the browser can't access 
the users mail in AA, and there never will be.


-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Thu, 21 Jun 2007, Chris Mason wrote:

> > The incomplete mediation flows from the design, since the pathname-based
> > mediation doesn't generalize to cover all objects unlike label- or
> > attribute-based mediation.  And the "use the natural abstraction for
> > each object type" approach likewise doesn't yield any general model or
> > anything that you can analyze systematically for data flow.
> 
> This feels quite a lot like a repeat of the discussion at the kernel
> summit.  There are valid uses for path based security, and if they don't
> fit your needs, please don't use them.  But, path based semantics alone
> are not a valid reason to shut out AA.

The validity or otherwise of pathname access control is not being 
discussed here.

The point is that the pathname model does not generalize, and that 
AppArmor's inability to provide adequate coverage of the system is a 
design issue arising from this.

Recall that the question asked by Lars was whether there were any 
outstanding technical issues relating to AppArmor.

AppArmor does not and can not provide the level of confinement claimed by 
the documentation, and its policy does not reflect its actual confinement 
properties.  That's kind of a technical issue, right?


- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Chris Mason]

On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> > 
> > > > A veto is not a technical argument. All technical arguments (except for
> > > > "path name is ugly, yuk yuk!") have been addressed, have they not?
> > > AppArmor doesn't actually provide confinement, because it only operates 
> > > on 
> > > filesystem objects.
> > > 
> > > What you define in AppArmor policy does _not_ reflect the actual 
> > > confinement properties of the policy.  Applications can simply use other 
> > > mechanisms to access objects, and the policy is effectively meaningless.
> > 
> > Only if they have access to another process which provides them with
> > that data.
> 
> Or can access the data under a different path to which their profile
> does give them access, whether in its final destination or in some
> temporary file processed along the way.
> 
> > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > that's a missing feature, not broken by design.
> 
> The incomplete mediation flows from the design, since the pathname-based
> mediation doesn't generalize to cover all objects unlike label- or
> attribute-based mediation.  And the "use the natural abstraction for
> each object type" approach likewise doesn't yield any general model or
> anything that you can analyze systematically for data flow.

This feels quite a lot like a repeat of the discussion at the kernel
summit.  There are valid uses for path based security, and if they don't
fit your needs, please don't use them.  But, path based semantics alone
are not a valid reason to shut out AA.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Thu, 21 Jun 2007, Joshua Brindle wrote:


Lars Marowsky-Bree wrote:

 On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
 


>  Um, no.  It might not be able to directly open files via that path, but
>  showing that it can never read or write your mail is a rather different
>  matter.
> 


 Yes. Your use case is different than mine.



So.. your use case is what? If an AA user asked you to protect his mail from 
his browser I'm sure you'd truthfully answer "no, we can't do that but we can 
protect the path to your mail from your browser".. I think not. One need only 
look at the wonderful marketing literature for AA to see what you are telling 
people it can do, and your above statement isn't consistent with that, sorry.


remember, the policies define a white-list

so if a hacker wants to have mozilla access the mail files he needs to get 
some other process on the sysstem to create a link or move a file to a 
path that mozilla does have access to. until that is done there is no way 
for mozilla to access the mail through the filesystem.


other programs could be run that would give mozilla access to the mail 
contents, but it would be through some other path that the policy 
permitted mozilla accessing in the first place.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-21T20:16:25, Joshua Brindle <[EMAIL PROTECTED]> wrote:

> not. One need only look at the wonderful marketing literature for AA to 
> see what you are telling people it can do, and your above statement 
> isn't consistent with that, sorry.

I'm sorry. I don't work in marketing.


-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

Lars Marowsky-Bree wrote:

On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:


  

Um, no.  It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.



Yes. Your use case is different than mine.
  


So.. your use case is what? If an AA user asked you to protect his mail 
from his browser I'm sure you'd truthfully answer "no, we can't do that 
but we can protect the path to your mail from your browser".. I think 
not. One need only look at the wonderful marketing literature for AA to 
see what you are telling people it can do, and your above statement 
isn't consistent with that, sorry.


-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[John Johansen]

On Thu, Jun 21, 2007 at 10:21:07PM +0200, Lars Marowsky-Bree wrote:
> On 2007-06-21T22:07:40, Pavel Machek <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Plus IIRC we have something like "AA has to allocate path-sized
> > buffers along every syscall".
> 
> That is an implementation bug though. I'm sure we have other bugs in the
> kernel too - this isn't a design flaw. 
> 
> (If people are allowed to thinair solutions for implementing AA on top
> of SELinux, I can thinair that this can be solved by reverse-matching
> the dentry tree against the policy as the path is traversed and
> constructed, requiring a constant sized buffer.)
> 
Indeed there are a few solutions to "fix" this implementation "bug",
of which reverse matching is one.  For reverse matching the policy
tables would become larger.   Reverse matching wouldn't need any
additional buffer for enforcement but would still fall back to d_path
for logging.

But we would still require the changes to the vfs and also a way to
safely walk the tree backwards.  So we would need to either export the
namespace semaphore or add a generic walking function which we could
pass a hook function to.


pgpOvWugBbVvn.pgp
Description: PGP signature

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:

> Or can access the data under a different path to which their profile
> does give them access, whether in its final destination or in some
> temporary file processed along the way.

Well, yes. That is intentional.

Your point is?

> The emphasis on never modifying applications for security in AA likewise
> has an adverse impact here, as you will ultimately have to deal with
> application mediation of access to their own objects and operations not
> directly visible to the kernel (as we have already done in SELinux for
> D-BUS and others and are doing for X).  Otherwise, your "protection" of
> desktop applications is easily subverted.

That is an interesting argument, but not what we're discussing here.
We're arguing filesystem access mediation.

> Um, no.  It might not be able to directly open files via that path, but
> showing that it can never read or write your mail is a rather different
> matter.

Yes. Your use case is different than mine.



Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> 
> > > A veto is not a technical argument. All technical arguments (except for
> > > "path name is ugly, yuk yuk!") have been addressed, have they not?
> > AppArmor doesn't actually provide confinement, because it only operates on 
> > filesystem objects.
> > 
> > What you define in AppArmor policy does _not_ reflect the actual 
> > confinement properties of the policy.  Applications can simply use other 
> > mechanisms to access objects, and the policy is effectively meaningless.
> 
> Only if they have access to another process which provides them with
> that data.

Or can access the data under a different path to which their profile
does give them access, whether in its final destination or in some
temporary file processed along the way.

> And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> that's a missing feature, not broken by design.

The incomplete mediation flows from the design, since the pathname-based
mediation doesn't generalize to cover all objects unlike label- or
attribute-based mediation.  And the "use the natural abstraction for
each object type" approach likewise doesn't yield any general model or
anything that you can analyze systematically for data flow.

The emphasis on never modifying applications for security in AA likewise
has an adverse impact here, as you will ultimately have to deal with
application mediation of access to their own objects and operations not
directly visible to the kernel (as we have already done in SELinux for
D-BUS and others and are doing for X).  Otherwise, your "protection" of
desktop applications is easily subverted.

> > You might define this as a non-technical issue, but the fact that AppArmor 
> > simply does not and can not work is a fairly significant consideration, I 
> > would imagine.
> 
> If I restrict my Mozilla to not access my on-disk mail folder, it can't
> get there. (Barring bugs in programs which Mozilla is allowed to run
> unconfined, sure.)

Um, no.  It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-21T22:07:40, Pavel Machek <[EMAIL PROTECTED]> wrote:

> > AA is supposed to allow valid access patterns, so for non-buggy apps +
> > policies, the rename will be fine and does not change the (observed)
> > permissions.
> That still breaks POSIX, right? Hopefully it will not break any apps,
> but...

No, it does not break POSIX.

Unless, of course, there's a bug in the policy or in the program. Bugs
are generally not covered by POSIX, for some strange reason.

(The argument that POSIX codifies implementation bugs in Unix(tm)
implementations of the time non-withstanding.)

> > A veto is not a technical argument. All technical arguments (except for
> > "path name is ugly, yuk yuk!") have been addressed, have they not?
> There still is "it does not work with long pathnames".
> 
> Plus IIRC we have something like "AA has to allocate path-sized
> buffers along every syscall".

That is an implementation bug though. I'm sure we have other bugs in the
kernel too - this isn't a design flaw. 

(If people are allowed to thinair solutions for implementing AA on top
of SELinux, I can thinair that this can be solved by reverse-matching
the dentry tree against the policy as the path is traversed and
constructed, requiring a constant sized buffer.)



Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> > I believe AA breaks POSIX, already. rename() is not expected to change
> > permissions on target, nor is link link. And yes, both of these make
> > AA insecure.
> 
> AA is supposed to allow valid access patterns, so for non-buggy apps +
> policies, the rename will be fine and does not change the (observed)
> permissions.

That still breaks POSIX, right? Hopefully it will not break any apps,
but...

> > > If that is the only way to implement AA on top of SELinux - and so far,
> > > noone has made a better suggestion - I'm convinced that AA has technical
> > > merit: it does something the on-disk label based approach cannot handle,
> > > and for which there is demand.
> > What demand? SELinux is superior to AA, and there was very little
> > demand for AA. Compare demand for reiser4 or suspend2 with demand for
> > AA.
> 
> SELinux is superior to AA for a certain scenario of use cases; as we can
> see here, it is not superior to AA for _all_ use cases.

The scenario where it does not seem superior is "I have system with AA
here and I'd like to keep using it".

> > > The code has improved, and continues to improve, to meet all the coding
> > > style feedback except the bits which are essential to AA's function
> > Which are exactly the bits Christoph Hellwig and Al Viro
> > vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> > . I believe it takes more than "2 users want it" to overcome veto of
> > VFS maintainer.
> 
> A veto is not a technical argument. All technical arguments (except for
> "path name is ugly, yuk yuk!") have been addressed, have they not?

There still is "it does not work with long pathnames".

Plus IIRC we have something like "AA has to allocate path-sized
buffers along every syscall".

I guess Al Viro or Christoph Hellwig would be able to detail on
that. I don't think they are vetoing stuff for fun.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:

> > A veto is not a technical argument. All technical arguments (except for
> > "path name is ugly, yuk yuk!") have been addressed, have they not?
> AppArmor doesn't actually provide confinement, because it only operates on 
> filesystem objects.
> 
> What you define in AppArmor policy does _not_ reflect the actual 
> confinement properties of the policy.  Applications can simply use other 
> mechanisms to access objects, and the policy is effectively meaningless.

Only if they have access to another process which provides them with
that data.

And now, yes, I know AA doesn't mediate IPC or networking (yet), but
that's a missing feature, not broken by design.

> You might define this as a non-technical issue, but the fact that AppArmor 
> simply does not and can not work is a fairly significant consideration, I 
> would imagine.

If I restrict my Mozilla to not access my on-disk mail folder, it can't
get there. (Barring bugs in programs which Mozilla is allowed to run
unconfined, sure.)

If the argument is that AA provides somewhat different semantics - and
for some use cases "weaker" ones - than SE Linux, that is undoubtly
true. However, it appears to be the case that those are the differences
which make AA's model different from SELinux as well, so it appears a
trade-off best left to the admin / user to choose what fits their needs
best.


Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> >>The code has improved, and continues to improve, to meet all the coding
> >>style feedback except the bits which are essential to AA's function
> >
> >Which are exactly the bits Christoph Hellwig and Al Viro
> >vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> >. I believe it takes more than "2 users want it" to overcome veto of
> >VFS maintainer.
> 
> so you are saying that _any_ pathname based solution is not acceptable to 
> the kernel, no matter what?

You'd have to ask Christoph the same question.

AFAICT, reconstructing full path then basing security on that is a
no-no.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Thu, 21 Jun 2007, Lars Marowsky-Bree wrote:

> A veto is not a technical argument. All technical arguments (except for
> "path name is ugly, yuk yuk!") have been addressed, have they not?

AppArmor doesn't actually provide confinement, because it only operates on 
filesystem objects.

What you define in AppArmor policy does _not_ reflect the actual 
confinement properties of the policy.  Applications can simply use other 
mechanisms to access objects, and the policy is effectively meaningless.

You might define this as a non-technical issue, but the fact that AppArmor 
simply does not and can not work is a fairly significant consideration, I 
would imagine.



- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-21T12:30:08, [EMAIL PROTECTED] wrote:

> well, if you _really_ want people who are interested in this to do weekly 
> "why isn't it merged yet you $%#$%# developers" threads that can be 
> arranged.
> 
> the people who want this have been trying to be patient and let the system 
> work. if it takes people being pests to get something implemented it can 
> be done, but I don't think other people on the list will appriciate this.

Please. We're so not going down _that_ route.


-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Thu, 21 Jun 2007, Pavel Machek wrote:


If that is the only way to implement AA on top of SELinux - and so far,
noone has made a better suggestion - I'm convinced that AA has technical
merit: it does something the on-disk label based approach cannot handle,
and for which there is demand.


What demand? SELinux is superior to AA, and there was very little
demand for AA. Compare demand for reiser4 or suspend2 with demand for
AA.


well, if you _really_ want people who are interested in this to do weekly 
"why isn't it merged yet you $%#$%# developers" threads that can be 
arranged.


the people who want this have been trying to be patient and let the system 
work. if it takes people being pests to get something implemented it can 
be done, but I don't think other people on the list will appriciate this.



The code has improved, and continues to improve, to meet all the coding
style feedback except the bits which are essential to AA's function


Which are exactly the bits Christoph Hellwig and Al Viro
vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
. I believe it takes more than "2 users want it" to overcome veto of
VFS maintainer.


so you are saying that _any_ pathname based solution is not acceptable to 
the kernel, no matter what?


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-21T20:33:11, Pavel Machek <[EMAIL PROTECTED]> wrote:

> inconvenient, yes, insecure, no.

Well, only if you use the most restrictive permissions. And then you'll
suddenly hit failure cases which you didn't expect to, which can
possibly cause another exploit to become visible.

> I believe AA breaks POSIX, already. rename() is not expected to change
> permissions on target, nor is link link. And yes, both of these make
> AA insecure.

AA is supposed to allow valid access patterns, so for non-buggy apps +
policies, the rename will be fine and does not change the (observed)
permissions.

The time window in the rename+relabel approach however introduces a slot
where permissions are not consistent. This is a different case.

> > You _must_ be kidding. The cure is worse than the problem.
> Possibly.

Yes.

> > If that is the only way to implement AA on top of SELinux - and so far,
> > noone has made a better suggestion - I'm convinced that AA has technical
> > merit: it does something the on-disk label based approach cannot handle,
> > and for which there is demand.
> What demand? SELinux is superior to AA, and there was very little
> demand for AA. Compare demand for reiser4 or suspend2 with demand for
> AA.

SELinux is superior to AA for a certain scenario of use cases; as we can
see here, it is not superior to AA for _all_ use cases.

> > The code has improved, and continues to improve, to meet all the coding
> > style feedback except the bits which are essential to AA's function
> Which are exactly the bits Christoph Hellwig and Al Viro
> vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> . I believe it takes more than "2 users want it" to overcome veto of
> VFS maintainer.

A veto is not a technical argument. All technical arguments (except for
"path name is ugly, yuk yuk!") have been addressed, have they not?



Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> I've caught up on this thread with growing disbelief while reading the
> mails, so much that I've found it hard to decide where to reply to.
> 
> So people are claiming that AA is ugly, because it introduces pathnames
> and possibly a regex interpreter. Ok, taste differs. We've got many
> different flavours of filesystems in the kernel because of that.
> 
> However, the suggested cure makes me cringe.
> 
> You're saying that relabeling file(s) from user-space after a rename is
> a possible solution.
> 
> This breaks POSIX - renames must be atomic. It is possibly insecure; if
> this is fixed by making a rename automatically default to restrictive
> permissions, it'll be even more inconvenient. It will break
> applications

inconvenient, yes, insecure, no.

I believe AA breaks POSIX, already. rename() is not expected to change
permissions on target, nor is link link. And yes, both of these make
AA insecure.

> You _must_ be kidding. The cure is worse than the problem.

Possibly.

> If that is the only way to implement AA on top of SELinux - and so far,
> noone has made a better suggestion - I'm convinced that AA has technical
> merit: it does something the on-disk label based approach cannot handle,
> and for which there is demand.

What demand? SELinux is superior to AA, and there was very little
demand for AA. Compare demand for reiser4 or suspend2 with demand for
AA.

> The code has improved, and continues to improve, to meet all the coding
> style feedback except the bits which are essential to AA's function

Which are exactly the bits Christoph Hellwig and Al Viro
vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
. I believe it takes more than "2 users want it" to overcome veto of
VFS maintainer.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

On Thu 2007-06-21 18:01:05, Andreas Gruenbacher wrote:
> On Saturday 16 June 2007 01:49, Greg KH wrote:
> > But for those types of models that do not map well to internal kernel
> > structures, perhaps they should be modeled on top of a security system that
> > does handle the internal kernel representation of things in the way the
> > kernel works.
> 
> How exactly are struct vfsmount and struct dentry not in-kernel structures?

That's what greg is talking about, AFAICT. Normal kernel code uses
struct vfsmount + struct dentry.

AA uses... guess what... char pathname[HUGE_VALUE].
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

I've caught up on this thread with growing disbelief while reading the
mails, so much that I've found it hard to decide where to reply to.

So people are claiming that AA is ugly, because it introduces pathnames
and possibly a regex interpreter. Ok, taste differs. We've got many
different flavours of filesystems in the kernel because of that.

However, the suggested cure makes me cringe.

You're saying that relabeling file(s) from user-space after a rename is
a possible solution.

This breaks POSIX - renames must be atomic. It is possibly insecure; if
this is fixed by making a rename automatically default to restrictive
permissions, it'll be even more inconvenient. It will break applications
which expect to be able to access the file(s) immediately after a
rename. It is slow, and can possibly cause a lot of disk access.
Possibly over NFS or via slow disks. By going through user-space - which
could block and introduce all sorts of memory deadlocks (compared to
that deadlock, a regex is harmless.) (I also wonder how you propose to
relabel files on a r/o mount if the policy changes, btw; or if the NFS
mount is made available on several nodes w/different permissions.) AA
only enforces user-space defined policy - the argument that policy
doesn't belong into the kernel is bull. Adding a wrapper to glibc to
block until relabeling is complete?

"Let's first do the implementation and later worry about performance."?
"The timing window is neglible."? "30 minutes during installation does
not seem silly."?

You _must_ be kidding. The cure is worse than the problem.

If that is the only way to implement AA on top of SELinux - and so far,
noone has made a better suggestion - I'm convinced that AA has technical
merit: it does something the on-disk label based approach cannot handle,
and for which there is demand.

The code has improved, and continues to improve, to meet all the coding
style feedback except the bits which are essential to AA's function
(like the pathname lookup and the regex parser; though I'm sure that in
particular the later one could be swapped for a less complex matcher as
well). It certainly isn't worse than many other areas of the kernel.

You're pointing to each other's opposition to the features - that, my
dear gentlemen, is a circular argument. One of you could readily break
the chain.

This is trying to get rid of AA for the sake of it, masquerading as
technical reasons. At least fucking admit it. Don't lie. This is
distasteful.


Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Andreas Gruenbacher]

On Saturday 16 June 2007 01:49, Greg KH wrote:
> But for those types of models that do not map well to internal kernel
> structures, perhaps they should be modeled on top of a security system that
> does handle the internal kernel representation of things in the way the
> kernel works.

How exactly are struct vfsmount and struct dentry not in-kernel structures?

Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Andreas Gruenbacher]

On Monday 18 June 2007 15:33, Stephen Smalley wrote:
> On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote:
> > There are two things:
> >
> > 1) relabeling (non-tranquility) is very problematic in general because
> > revocation is hard (and non-solved in Linux). So you would have to
> > address concerns about that.
>
> I think we need to distinguish between relying on restorecond-like
> mechanisms for the security of SELinux vs. relying on them for emulating
> pathname-based security.  The former would be a problem.  The latter is
> no worse than pathname-based security already, because pathname-based
> security is inherently ambiguous and non-tranquil, and revocation isn't
> addressed fully in AA either.

Emulation using lazy relabeling introduces a window where the files have the 
wrong label. In those windows, the pathname based policy is being violated, 
and unintended side effects are suddenly possible. This includes granting of 
access to files that applications should no longer have access to according 
to the pathname based policy, which would be similar to what happens when a 
process keeps an open file handle right now. But it also includes denial of 
access to files that applications should have access to, and this might cause 
those applications to fail. So this is where relabeling from user space is 
much worse.

The only way to get rid of the denial of service problem would be to make the 
rename and relabel an atomic operation. The time this can take is huge 
though, so that's not acceptable.

Another, less catastrophic problem is that rename has always been relatively 
fast and inexpensive, and I'm sure plenty of applications rely on this 
performance characteristic. Making rename a very expensive operation in at 
least some cases (which are more than theoretical) would hurt those 
applications, and nothing much could be done about it.

Adding better new-file mechanisms to SELinux probably is a good idea, and it 
would weaken the SELinux seurity model for all I can tell. It doesn't address 
the relabeling problem though.

Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Crispin Cowan]

Greg KH wrote:
> On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
>   
>> Then there's all the other problems, such as file systems that don't
>> support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable
>> to network attack, but that is not the threat AA is addressing. AA is
>> preventing an application with access to an NFS mount from accessing the
>> *entire* mount. There is lots of practical security value in this, and
>> label schemes cannot do it. Well, mostly; you could do it with a dynamic
>> labeling scheme that labels files as they are pulled into kernel memory,
>> but that requires an AA-style regexp parser in the kernel to apply the
>> labels.
>> 
> You still haven't answered Stephen's response to NFSv3, so until then,
> please don't trot out this horse.
>   
Ok then ...

Stephen Smalley wrote:
> - File systems that do not support labels:  I'm a bit surprised that you
> would advocate this given your experience in developing EA and ACL
> support for local filesystems and NFS.  The pathname-based approach in
> NFS seems even scarier than in the local case - the clients may have
> different views of the namespace than one another or the server and the
> potential for inconsistent views of the tree (particularly as it is
> being modified) during access checks is only greater in the NFS case,
> right?  It may be more expedient to implement, but is it the right
> technical approach?
I'm actually unclear on what the question is. Stephen appears to be
thinking of confining the NFS server daemon, and our intended use case
is to use AppArmor to confine applications that access data on NFS clients.

* Each NFS *client* machine has a view of the NFS mount point that
  is consistent for that client.
* The AA confinement is of the application accessing the NFS mount
  on the client, *not* the NFS server daemon.
* The fact that the views of multiple clients are different from
  each other is irrelevant, because we are confining applications on
  the client, not the NFS server daemon.
* As noted in Andreas' technical document
  http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
  there is no purpose to confining the NFS server daemon; it is a
  kernel process, and if it mis-behaves, it can completely subvert
  any kernel security policy, including AA and SELinux.

Since this point seems to be subtle, here's a motivating example.
Consider I have a diskless workstation, and my home dir /home/crispin is
NFS mounted from a big NAS server over there. I like to run my FireFox
confined, so that it only has access to /home/crispin/.mozilla/** and
/home/crispin/Downloads/** so that if my browser is compromised, the
attacker doesn't get to my /home/.ssh* stuff.

Yes, the data served over NFS is vulnerable to a local network attack,
but that is not what AA is preventing here. The threat is coming from
attacks that make the web browser misbehave.

Under SELinux, I either give the web browser access to all of
/home/crispin (the entire mount point) or none of it. Under AA, the
pathname specification works fine, we can control which directories on
the mount point the application can access.

The same argument applies to server applications that access data served
NFS mount points. Consider a large application server that hosts all my
enterprise resource management stuff, and a large NAS server that hosts
the data. Perhaps the NAS server is a Network Appliance server, not even
using a Linux file system, just supplying NFS3 mounts.

The application server is hosting both the payroll system and the
customer relationship application. The data for both are on the NetApp,
serviced via NFS to the application server. I want to confine the
payroll application to access only the payroll data, and the CRM
application to access only CRM data.

The only way SELinux could do this would be to have anticipated the
problem and store my data on separate partitions, so you could supply
separate mount points. AppArmor can just use path specifications to
confine each application to its own part of a single NFS mount point. In
a perfect world the admin would use separate mount points, AppArmor is a
tool for an imperfect world.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote:
> On Fri, 2007-06-15 at 14:44 -0700, Greg KH wrote:
> > On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> > > On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > > > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > > > > 
> > > > > Yup, I see that once you accept the notion that it is OK for a
> > > > > file to be misslabeled for a bit and that having a fixxerupperd
> > > > > is sufficient it all falls out.
> > > > > 
> > > > > My point is that there is a segment of the security community
> > > > > that had not found this acceptable, even under the conditions
> > > > > outlined. If it meets your needs, I say run with it.
> > > > 
> > > > If that segment feels that way, then I imagine AA would not meet their
> > > > requirements today due to file handles and other ways of passing around
> > > > open files, right?
> > > > 
> > > > So, would SELinux today (without this AA-like daemon) fit the
> > > > requirements of this segment?
> > > > 
> > > 
> > > Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
> > > using the features of SELinux where appropriate.
> > 
> > Great, but is there the requirement in the CC stuff such that this type
> > of "delayed re-label" that an AA-like daemon would need to do cause that
> > model to not be able to be certified like your SELinux implementation
> > is?
> > 
> 
> There are two things:
> 
> 1) relabeling (non-tranquility) is very problematic in general because
> revocation is hard (and non-solved in Linux). So you would have to
> address concerns about that.

I think we need to distinguish between relying on restorecond-like
mechanisms for the security of SELinux vs. relying on them for emulating
pathname-based security.  The former would be a problem.  The latter is
no worse than pathname-based security already, because pathname-based
security is inherently ambiguous and non-tranquil, and revocation isn't
addressed fully in AA either.

> 
> 2) Whether this would pass certification depends on a lot of factors
> (like the specific requirements - CC is just a process not a single set
> of requirements). I don't know enough to really guess.
> 
> More to the point, though, the requirements in those documents are
> outdated at best. I don't think it is worth worrying over.
> 
> > As I'm guessing the default "label" for things like this already work
> > properly for SELinux, I figure we should be safe, but I don't know those
> > requirements at all.
> > 
> 
> Probably not - you would likely want it to be a label that can't be read
> or written by anything, only relabeled by the daemon.
> 
> Karl
> 
-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Fri, 2007-06-15 at 13:43 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> 
> > On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> > > --- Greg KH <[EMAIL PROTECTED]> wrote:
> > > 
> > > 
> > > > A daemon using inotify can "instantly"[1] detect this and label the file
> > > > properly if it shows up.
> > > 
> > > In our 1995 B1 evaluation of Trusted Irix we were told in no
> > > uncertain terms that such a solution was not acceptable under
> > > the TCSEC requirements. Detection and relabel on an unlocked
> > > object creates an obvious window for exploitation. We were told
> > > that such a scheme would be considered a design flaw.
> > > 
> > > I understand that some of the Common Criteria labs are less
> > > aggressive regarding chasing down these issues than the NCSC
> > > teams were. It might not prevent an evaluation from completing
> > > today. It is still hard to explain why it's ok to have a file
> > > that's labeled incorrectly _even briefly_. It is the systems
> > > job to ensure that that does not happen.
> > 
> > Um, Casey, he is talking about how to emulate AppArmor behavior on a
> > label-based system like SELinux,
> 
> Yes. What I'm saying (or trying to) is that such an implementation
> would be flawed by design.
> 
> > not meeting B1 or LSPP or anything like that
> > (which AppArmor can't do regardless).
> 
> We're not talking about an implementation based on AppArmor. As
> you point out, we're talking about implementing name based access
> control as an extension of SELinux.

We're talking about emulating pathname-based security on SELinux.
Pathname-based security is inherently non-tranquil (names can change at
any time) and ambiguous (a single name may refer to different objects in
different namespaces, multiple names may refer to the same object in a
single namespace), and thus cannot possibly meet information flow  /
classical confinement requirements.  So using restorecond as the basis
for such an emulation loses nothing from what you already had.  Using
restorecond as the fundamental basis for the security of SELinux itself
would be a bad thing, agreed.

> > As far as general issue
> > goes, if your policy is configured such that the new file gets the most
> > restrictive label possible at creation time and then the daemon relabels
> > it to a less restrictive label if appropriate, then there is no actual
> > window of exposure.
> 
> Is it general practice to configure policy such that "the new file gets
> the most restrictive label possible at creation time"? I confess that
> my understanding of the current practice in policy generation is based
> primarily on a shouted conversation in a crowded Irish pub.
> 
> > Also, there is such a daemon, restorecond, in SELinux (policycoreutils)
> > although we avoid relying on it for anything security-critical
> > naturally.
> 
> Yes, I am aware of restorecond. I find the need for restorecond troubling.

Understand that we view it as a method of last resort, only to be
considered after trying first to:
1) Configure policy transparently to label the file correctly at
creation time (based on the creating process' label, the parent
directory label, and the kind of file), or if that fails,
2) Modify the library or application code to label the file correctly at
creation time (e.g. when multiple files that should be protected
differently are created by the same process in the same directory,
e.g. /etc/passwd vs. /etc/shadow).

> > And one could introduce the named type transition concept
> > that has been discussed in this thread without much difficulty to
> > selinux.
> 
> Yup, I see that once you accept the notion that it is OK for a
> file to be misslabeled for a bit and that having a fixxerupperd
> is sufficient it all falls out.

I think you misunderstand what I mean by named type transition here -
that is a reference to earlier discussions in this thread on extending
the SELinux type_transition statements to let the kernel directly label
new files based not only on creating process and parent directory label
but also the last component name.  With such an extension, SELinux could
directly distinguish e.g. /etc/shadow from /etc/passwd at file creation
time in the kernel without needing anything like restorecond in
userspace.  There is no temporary mislabeling with such a mechanism.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Joshua Brindle]

Casey Schaufler wrote:

--- James Morris <[EMAIL PROTECTED]> wrote:

  

On Fri, 15 Jun 2007, Casey Schaufler wrote:



--- James Morris <[EMAIL PROTECTED]> wrote:

  
On my system, it takes about 1.2 seconds to label a fully checked out 
kernel source tree with ~23,000 files in this manner


That's an eternity for that many files to be improperly labeled.
If, and the "if" didn't originate with me, your policy is
demonstrably correct (how do you do that?) for all domains
you could claim that the action is safe, if not ideal. 
I can't say if an evaluation team would buy the "safe"

argument. They've been known to balk before.
  

To clarify:

We are discussing a scheme where the underlying SELinux labeling policy 
always ensures a safe label on a file, and then relabeling newly created 
files according to their pathnames.



To counter clarify:

You are saying two things:
1. The policy always ensures a safe label.
2. Files can be relabeled in a reasonable and timely manner.

I have no questions about 2. It's a hack, but you've already
acknowledged that and it will work, allowing for some potential
cases where someone is overeager about getting a file-in-transition.

Regarding 1: This is a founding premise of the arguement, that
the "policy" is written correctly such that there is no case
where a file gets created with an unsafe label. Given the external
nature of the policy, and the number of attributes used within
the policy, and the overall sophistication of the policy mechanism,
how does one ...

a. know that a label is "safe"
b. know that a file will get a "safe" label
c. know that the policy is "correctly" written as required

The question is not if fixxerupperd can set things right.
The question is about the properly written policy that is
required to make the mechanism worth discussing.

  


There are only about 850 file type_transition rules in the policy 
shipped with RHEL and the vast majority of them are templated so this 
isn't as hard as you think. Most are things like:

  type_transition ftpd_t tmp_t : file ftpd_tmp_t;

which 1) don't require relabeling to something else and 2) very easy to 
audit. A quick look suggests that the potentially less-restrictive label 
is never chosen, for example you'll see:

  type_transition groupadd_t etc_t : file shadow_t;
  type_transition useradd_t etc_t : file shadow_t;

Instead of the default transition being etc_t they are labeled as 
shadow_t (more restrictive) and then potentially relabled to etc_t.


That said, the lack of a type_transition in this case is as important as 
having one if the default type (the parent directory) is less 
restrictive. We already have tools that analyze policy and even tools to 
warn about potential errors in policy (apol and sechecker). It might be 
a good idea to add some more analysis to these tools to point out 
potential labeling errors that can be used in automatic analysis, which 
shouldn't be hard, I'll be sure to suggest that to the setools developers.


There is no expectation that this scheme would be submitted for 
certification.



De-nial.

  


Several systems have gone off to ct&e and none of them use restorecond. 
These are custom build systems and relabeling is kept to a minimum and 
the applications are architected in a way that precludes this being 
necessary so I don't know what you are trying to get at here.


Its purpose is to merely to provide pathname-based 
labeling outside of the kernel.



If you already have an in-kernel labeling scheme that you
trust to make the world safe until you get around to doing
the labeling externally you can argue that it's good enough.
But, to quote Cinderella's Stepmother, "I said "if"".
  


The "if" for SELinux is alot easier than you suggest. It certainly 
outweighs the disadvantages of the path based scheme IMHO.

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Casey Schaufler]

--- James Morris <[EMAIL PROTECTED]> wrote:

> On Fri, 15 Jun 2007, Casey Schaufler wrote:
> 
> > 
> > --- James Morris <[EMAIL PROTECTED]> wrote:
> > 
> > > On my system, it takes about 1.2 seconds to label a fully checked out 
> > > kernel source tree with ~23,000 files in this manner
> > 
> > That's an eternity for that many files to be improperly labeled.
> > If, and the "if" didn't originate with me, your policy is
> > demonstrably correct (how do you do that?) for all domains
> > you could claim that the action is safe, if not ideal. 
> > I can't say if an evaluation team would buy the "safe"
> > argument. They've been known to balk before.
> 
> To clarify:
> 
> We are discussing a scheme where the underlying SELinux labeling policy 
> always ensures a safe label on a file, and then relabeling newly created 
> files according to their pathnames.

To counter clarify:

You are saying two things:
1. The policy always ensures a safe label.
2. Files can be relabeled in a reasonable and timely manner.

I have no questions about 2. It's a hack, but you've already
acknowledged that and it will work, allowing for some potential
cases where someone is overeager about getting a file-in-transition.

Regarding 1: This is a founding premise of the arguement, that
the "policy" is written correctly such that there is no case
where a file gets created with an unsafe label. Given the external
nature of the policy, and the number of attributes used within
the policy, and the overall sophistication of the policy mechanism,
how does one ...

a. know that a label is "safe"
b. know that a file will get a "safe" label
c. know that the policy is "correctly" written as required

The question is not if fixxerupperd can set things right.
The question is about the properly written policy that is
required to make the mechanism worth discussing.

> There is no expectation that this scheme would be submitted for 
> certification.

De-nial.

> Its purpose is to merely to provide pathname-based 
> labeling outside of the kernel.

If you already have an in-kernel labeling scheme that you
trust to make the world safe until you get around to doing
the labeling externally you can argue that it's good enough.
But, to quote Cinderella's Stepmother, "I said "if"".


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Sat, Jun 16, 2007 at 01:09:06AM -0700, [EMAIL PROTECTED] wrote:
>  On Fri, 15 Jun 2007, Greg KH wrote:
> 
> >>> Usually you don't do that by doing a 'mv' otherwise you are almost
> >>> guaranteed stale and mixed up content for some period of time, not to
> >>> mention the issues surrounding paths that might be messed up.
> >>
> >>  on the contrary, useing 'mv' is by far the cleanest way to do this.
> >>
> >>  mv htdocs htdocs.old;mv htdocs.new htdocs
> >>
> >>  this makes two atomic changes to the filesystem, but can generate 
> >> thousands
> >>  to millions of permission changes as a result.
> >
> > I agree, and yet, somehow, SELinux today handles this just fine, right?
> > :)
> 
>  no it doesn't, SELinux as-is should take no action when the above command is 
>  run, but SELinux implementing path-based permissions will have to relabel 
>  every file or directory in both trees.

Agreed.

> > Let's worry about speed issues later on when a working implementation is
> > produced, I'm still looking for the logical reason a system like this
> > can not work properly based on the expected AA interface to users.
> 
>  if you are willing to live with the race conditions from the slow 
>  (re)labeling and write the software to scan the entire system to figure out 
>  the right policies (and then use inotify to watch the entire system for 
>  changes and (re)label the appropriate files) and accept that you can't get 
>  any granular security for filesystems that don't nativly support it you 
>  could make SELinux behave like AA.

You make it sound like such a pretty picture :)

Anyway, I don't think there are "race conditions", just a bit of a delay
at times for situations that are not common or "normal operations".  And
as I think the speed issues can be drasticly reduced, I don't think
that's a really big deal just yet.  I'm trying to determine if there's
any logical reason why we can't do this and have yet to see proof of
that.

>  but why should they be required to? are you saying that the LSM hooks are 
>  not a valid API and should be removed with all future security modules being 
>  based on SELinux?

Woah, that's a huge logical jump that I am not willing to make at this
point in time.

The reason I am proposing this for AA is due to the impeadance between
the AA model and how the kernel internally works.  A number of core
kernel  VFS developers have objected to the AA code and changes because
of this problem and me and Pavel are here working to try to resolve this
in a way that is acceptable to everyone involved (kernel developers and
AA developers and AA end users.)

I'll leave the whole "LSM should be just replaced with SELinux"
discussion for later, as it is not relevant to this current topic at
all.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Fri, 15 Jun 2007, Greg KH wrote:


Usually you don't do that by doing a 'mv' otherwise you are almost
guaranteed stale and mixed up content for some period of time, not to
mention the issues surrounding paths that might be messed up.


 on the contrary, useing 'mv' is by far the cleanest way to do this.

 mv htdocs htdocs.old;mv htdocs.new htdocs

 this makes two atomic changes to the filesystem, but can generate thousands
 to millions of permission changes as a result.


I agree, and yet, somehow, SELinux today handles this just fine, right?
:)


no it doesn't, SELinux as-is should take no action when the above command 
is run, but SELinux implementing path-based permissions will have to 
relabel every file or directory in both trees.



Let's worry about speed issues later on when a working implementation is
produced, I'm still looking for the logical reason a system like this
can not work properly based on the expected AA interface to users.


if you are willing to live with the race conditions from the slow 
(re)labeling and write the software to scan the entire system to figure 
out the right policies (and then use inotify to watch the entire system 
for changes and (re)label the appropriate files) and accept that you can't 
get any granular security for filesystems that don't nativly support it 
you could make SELinux behave like AA.


but why should they be required to? are you saying that the LSM hooks are 
not a valid API and should be removed with all future security modules 
being based on SELinux?


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 09:21:57PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
> 
> > Oh great, then things like source code control systems would have no
> > problems with new files being created under them, or renaming whole
> > trees.
> 
> It depends -- I think we may be talking about different things.
> 
> If you're using inotify to watch for new files and kick something in 
> userspace to relabel them, it could take a while to relabel a lot of 
> files, although there are likely some gains to be had from parallel 
> relabeling which we've not explored.
> 
> What I was saying is that you can use traditional SELinux labeling policy 
> underneath that to ensure that there is always a safe label on each file 
> before it is relabeled from userspace.

Ok, yes, I think we are in violent agreement here :)

> > So, so much for the "it's going to be too slow re-labeling everything"
> > issue, as it's not even required for almost all situations :)
> 
> You could probably get an idea of the cost by running something like:
> 
> $ time find /usr/src/linux | xargs setfattr -n user.foo -v bar
> 
> On my system, it takes about 1.2 seconds to label a fully checked out 
> kernel source tree with ~23,000 files in this manner, on a stock standard 
> ext3 filesystem with a SATA drive.

Yeah, that should be very reasonable.  I'll wait to see Crispin's code
to work off of and see if I can get it to approach that kind of speed.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, Casey Schaufler wrote:

> 
> --- James Morris <[EMAIL PROTECTED]> wrote:
> 
> > On my system, it takes about 1.2 seconds to label a fully checked out 
> > kernel source tree with ~23,000 files in this manner
> 
> That's an eternity for that many files to be improperly labeled.
> If, and the "if" didn't originate with me, your policy is
> demonstrably correct (how do you do that?) for all domains
> you could claim that the action is safe, if not ideal. 
> I can't say if an evaluation team would buy the "safe"
> argument. They've been known to balk before.

To clarify:

We are discussing a scheme where the underlying SELinux labeling policy 
always ensures a safe label on a file, and then relabeling newly created 
files according to their pathnames.

There is no expectation that this scheme would be submitted for 
certification.  Its purpose is to merely to provide pathname-based 
labeling outside of the kernel.



- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Casey Schaufler]

--- James Morris <[EMAIL PROTECTED]> wrote:

> On my system, it takes about 1.2 seconds to label a fully checked out 
> kernel source tree with ~23,000 files in this manner

That's an eternity for that many files to be improperly labeled.
If, and the "if" didn't originate with me, your policy is
demonstrably correct (how do you do that?) for all domains
you could claim that the action is safe, if not ideal. 
I can't say if an evaluation team would buy the "safe"
argument. They've been known to balk before.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, Seth Arnold wrote:

> The time for restorecon is probably best imagined as a kind of 'du' that
> also updates extended attributes as it does its work. It'd be very
> difficult to improve on this.

restorecon can most definitely be improved. 


- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, Seth Arnold wrote:

> > How does inotify not work here?  You are notified that the tree is
> > moved, your daemon goes through and relabels things as needed.  In the
> > meantime, before the re-label happens, you might have the wrong label on
> > things, but "somehow" SELinux already handles this, so I think you
> > should be fine.
> 
> SELinux does not relabel files when containing directories move, so it
> is not a problem they've chosen to face.

It's a deliberate design choice, and follows traditional Unix security 
logic.  DAC permissions don't change on every file in the subtree when you 
mv directories, either.




- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote:

> on the contrary, useing 'mv' is by far the cleanest way to do this.
> 
> mv htdocs htdocs.old;mv htdocs.new htdocs
> 
> this makes two atomic changes to the filesystem, but can generate thousands to
> millions of permission changes as a result.

OTOH, you've performed your labeling up front, and don't have to 
effectively relabel each file each time on each access, which is what 
you're really doing with pathname labeling.



- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, Greg KH wrote:

> Oh great, then things like source code control systems would have no
> problems with new files being created under them, or renaming whole
> trees.

It depends -- I think we may be talking about different things.

If you're using inotify to watch for new files and kick something in 
userspace to relabel them, it could take a while to relabel a lot of 
files, although there are likely some gains to be had from parallel 
relabeling which we've not explored.

What I was saying is that you can use traditional SELinux labeling policy 
underneath that to ensure that there is always a safe label on each file 
before it is relabeled from userspace.

> So, so much for the "it's going to be too slow re-labeling everything"
> issue, as it's not even required for almost all situations :)

You could probably get an idea of the cost by running something like:

$ time find /usr/src/linux | xargs setfattr -n user.foo -v bar

On my system, it takes about 1.2 seconds to label a fully checked out 
kernel source tree with ~23,000 files in this manner, on a stock standard 
ext3 filesystem with a SATA drive.



- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 05:01:25PM -0700, [EMAIL PROTECTED] wrote:
>  On Fri, 15 Jun 2007, Greg KH wrote:
> 
> > On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> >> Greg KH wrote:
> >>> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
>  Only case where attacker _can't_ be keeping file descriptors is newly
>  created files in recently moved tree. But as you already create files
>  with restrictive permissions, that's okay.
> 
>  Yes, you may get some -EPERM during the tree move, but AA has that
>  problem already, see that "when madly moving trees we sometimes
>  construct path file never ever had".
> 
> >>> Exactly.
> >>>
> >> You are remembering old behavior. The current AppArmor generates only
> >> correct and consistent paths. If a process has an open file descriptor
> >> to such a file, they will retain access to it, as we described here:
> >> http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
> >>
> >> Under the restorecon-alike proposal, you have a HUGE open race. This
> >> post http://bugs.centos.org/view.php?id=1981 describes restorecon
> >> running for 30 minutes relabeling a file system. That is so far from
> >> acceptable that it is silly.
> >
> > Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
> > only problem we have here, it isn't an issue.
> 
>  how do you 'fix' the laws of physics?
> 
>  the problem is that with a directory that contains lots of files below it 
>  you have to access all the files metadata to change the labels on it. it can 
>  take significant amounts of time to walk the entire three and change every 
>  file.

Agreed, but you can do this in ways that are faster than others :)

> >>> I can't think of a "real world" use of moving directory trees around
> >>> that this would come up in as a problem.
> >> Consider this case: We've been developing a new web site for a month,
> >> and testing it on the server by putting it in a different virtual
> >> domain. We want to go live at some particular instant by doing an mv of
> >> the content into our public HTML directory. We simultaneously want to
> >> take the old web site down and archive it by moving it somewhere else.
> >>
> >> Under the restorecon proposal, the web site would be horribly broken
> >> until restorecon finishes, as various random pages are or are not
> >> accessible to Apache.
> >
> > Usually you don't do that by doing a 'mv' otherwise you are almost
> > guaranteed stale and mixed up content for some period of time, not to
> > mention the issues surrounding paths that might be messed up.
> 
>  on the contrary, useing 'mv' is by far the cleanest way to do this.
> 
>  mv htdocs htdocs.old;mv htdocs.new htdocs
> 
>  this makes two atomic changes to the filesystem, but can generate thousands 
>  to millions of permission changes as a result.

I agree, and yet, somehow, SELinux today handles this just fine, right?
:)

Let's worry about speed issues later on when a working implementation is
produced, I'm still looking for the logical reason a system like this
can not work properly based on the expected AA interface to users.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 05:18:10PM -0700, Seth Arnold wrote:
> On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > > We have built a label-based AA prototype. It fails because there is no
> > > reasonable way to address the tree renaming problem.
> > 
> > How does inotify not work here?  You are notified that the tree is
> > moved, your daemon goes through and relabels things as needed.  In the
> > meantime, before the re-label happens, you might have the wrong label on
> > things, but "somehow" SELinux already handles this, so I think you
> > should be fine.
> 
> SELinux does not relabel files when containing directories move, so it
> is not a problem they've chosen to face.
> 
> How well does inotify handle running attached to every directory on a
> typical Linux system?

Look at SLED and Beagle (taking the indexing logic out of the equation.)
It runs good enough that a major Linux vendor is willing to stake its
reputation on it :)

> > > Under the restorecon-alike proposal, you have a HUGE open race. This
> > > post http://bugs.centos.org/view.php?id=1981 describes restorecon
> > > running for 30 minutes relabeling a file system. That is so far from
> > > acceptable that it is silly.
> > 
> > Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
> > only problem we have here, it isn't an issue.
> 
> Restorecon traverses the filesystem from a specific down. In order to
> apply to an entire system (as would be necessary to try to emulate
> AppArmor's model using SELinux), restorecon would need to run on vast
> portions of the filesystem often. (mv ~/public_html ~/archived; or tar
> zxvf linux-*.tar.gz, etc.)
> 
> I'm not sure we need to run restorecon every time rename(2) is called.

Ok, so we optimize it.  Putting speed issues aside right now as a "mere"
implementation details, I'm looking for logical reasons the AA model
will not work in this type of system.

> > > Of course, this depends on the system in question, but restorecon will
> > > necessarily need to traverse whatever portions of the filesystem that
> > > have changed, which can be quite a long time indeed. Any race condition
> > > measured in minutes is a very serious issue.
> > 
> > Agreed, so we fix that.  There are ways to speed those kinds of things
> > up quite a bit, and I imagine since the default SELinux behavior doesn't
> > use restorecon in this kind of use-case, no one has spent the time to do
> > the work.
> 
> The time for restorecon is probably best imagined as a kind of 'du' that
> also updates extended attributes as it does its work. It'd be very
> difficult to improve on this.

Is that a bet?  :)

> > What "kernel memory and performance" issues are there?  Your SLED
> > machine already has inotify running on every directory in the system
> > today, and you don't seem to have noticed that :)
> 
> I beg to differ. :)

The Beagle index backend is known to slow things down at times, yes, but
is that the fault of the inotify watches, or the use of mono and a
big-ass database on the system at the same time?

In the original inotify development, the issue was not inotify at all,
unless you have some newer numbers in this regard?

And Crispin mentioned that you all already implemented this.  Do you
have the code around so that we can take a look at it?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> >>Under the restorecon proposal, the web site would be horribly broken
> >>until restorecon finishes, as various random pages are or are not
> >>accessible to Apache.
> >
> >Usually you don't do that by doing a 'mv' otherwise you are almost
> >guaranteed stale and mixed up content for some period of time, not to
> >mention the issues surrounding paths that might be messed up.
> 
> on the contrary, useing 'mv' is by far the cleanest way to do this.
> 
> mv htdocs htdocs.old;mv htdocs.new htdocs
> 
> this makes two atomic changes to the filesystem, but can generate 
> thousands to millions of permission changes as a result.

Ok, so mv gets slower for big trees... and open() gets faster for deep
trees. Previously, open in current directory was one atomic read of
directory entry, now it has to read directory, and its parent, and its
parent parent, and its...

(Or am I wrong and getting full path does not need to bring anything
in, not even in cache-cold case?)

So, proposed solution has different performance tradeoffs, but should
still be a win -- opens are more common than moves.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Seth Arnold]

On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > We have built a label-based AA prototype. It fails because there is no
> > reasonable way to address the tree renaming problem.
> 
> How does inotify not work here?  You are notified that the tree is
> moved, your daemon goes through and relabels things as needed.  In the
> meantime, before the re-label happens, you might have the wrong label on
> things, but "somehow" SELinux already handles this, so I think you
> should be fine.

SELinux does not relabel files when containing directories move, so it
is not a problem they've chosen to face.

How well does inotify handle running attached to every directory on a
typical Linux system?

> > Under the restorecon-alike proposal, you have a HUGE open race. This
> > post http://bugs.centos.org/view.php?id=1981 describes restorecon
> > running for 30 minutes relabeling a file system. That is so far from
> > acceptable that it is silly.
> 
> Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
> only problem we have here, it isn't an issue.

Restorecon traverses the filesystem from a specific down. In order to
apply to an entire system (as would be necessary to try to emulate
AppArmor's model using SELinux), restorecon would need to run on vast
portions of the filesystem often. (mv ~/public_html ~/archived; or tar
zxvf linux-*.tar.gz, etc.)

I'm not sure we need to run restorecon every time rename(2) is called.

> > Of course, this depends on the system in question, but restorecon will
> > necessarily need to traverse whatever portions of the filesystem that
> > have changed, which can be quite a long time indeed. Any race condition
> > measured in minutes is a very serious issue.
> 
> Agreed, so we fix that.  There are ways to speed those kinds of things
> up quite a bit, and I imagine since the default SELinux behavior doesn't
> use restorecon in this kind of use-case, no one has spent the time to do
> the work.

The time for restorecon is probably best imagined as a kind of 'du' that
also updates extended attributes as it does its work. It'd be very
difficult to improve on this.

> What "kernel memory and performance" issues are there?  Your SLED
> machine already has inotify running on every directory in the system
> today, and you don't seem to have noticed that :)

I beg to differ. :)


pgp4PjM5RH2rc.pgp
Description: PGP signature

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Seth Arnold]

On Sat, Jun 16, 2007 at 01:39:14AM +0200, Pavel Machek wrote:
> > Pavel, please focus on the current AppArmor implementation. You're
> > remembering a flaw with a previous version of AppArmor. The pathnames
> > constructed with the current version of AppArmor are consistent and
> > correct.
> 
> Ok, I did not know that this got fixed.
> 
> How do you do that? Hold a lock preventing renames for a whole time
> you walk from file to the root of filesystem?

We've improved d_path() to remove many of its previous shortcomings:

eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1


pgpWzjYHnHhk0.pgp
Description: PGP signature

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> >> Only case where attacker _can't_ be keeping file descriptors is newly
> >> created files in recently moved tree. But as you already create files
> >> with restrictive permissions, that's okay.
> >>
> >> Yes, you may get some -EPERM during the tree move, but AA has that
> >> problem already, see that "when madly moving trees we sometimes
> >> construct path file never ever had".
> >> 
> > Exactly.
> >   
> You are remembering old behavior. The current AppArmor generates only
> correct and consistent paths. If a process has an open file descriptor
> to such a file, they will retain access to it, as we described here:

Ok, so what I described was actually secure. Good.

> Under the restorecon-alike proposal, you have a HUGE open race. This
> post http://bugs.centos.org/view.php?id=1981 describes restorecon
> running for 30 minutes relabeling a file system. That is so far from
> acceptable that it is silly.

30 minutes during installation does not seem "silly" to me.

And that race does not make it insecure, because of the open file
descriptors. Good.

> Of course, this depends on the system in question, but restorecon will
> necessarily need to traverse whatever portions of the filesystem that
> have changed, which can be quite a long time indeed. Any race condition
> measured in minutes is a very serious issue.

You seem to imply it is security related, it is not. I can have open
files for hours or days.

> > I can't think of a "real world" use of moving directory trees around
> > that this would come up in as a problem.
> Consider this case: We've been developing a new web site for a month,
> and testing it on the server by putting it in a different virtual
> domain. We want to go live at some particular instant by doing an mv of
> the content into our public HTML directory. We simultaneously want to
> take the old web site down and archive it by moving it somewhere
> else.

And you do that exactly how, without the race? I do not think ve have
three_way_rename(name1, name2, name3) system call.

Notice that

1) mv can take minutes already if you move cross filesystem.

2) this is easily avoided by mv-ing somewhere with "same" permissons,
then doing quick moves when daemon is done.

> You could get restorecon to do this automatically by using inotify. But
> to make it as general and transparent as AA is now, you would have to
> run inotify on every directory in the system, with consequences for
> kernel memory and performance.

So you run inotify everywhere. IIRC beagle does it already.

> > Can anyone else see a problem with this that I'm just being foolish and
> > missing?
> >   
> It is not foolish. The label idea is so attractive that last September
> from discussions with Arjan we actually thought it was the preferred
> implementation. However, what we've been saying over and over again is
> that we *tried* this, and it *doesn't* work at the implementation level.
> There is no good answer, restorecon is an ugly kludge, and so this
> seductive approach turns out to be a dead end.

Talking about dead ends... "just put path-based security module into
kernel" recently got pretty strong "NACK" from Christoph Hellwig (see
TOMOYO Linux thread), and I believe there was similar comment from Al
Viro in past. That seems to me as dead-endy as it gets. "mv takes 30
minutes" is road slightly covered with bushes... compared to that.

So we can either forget about AA completely, or take a way Christoph
did not "NACK". restorecond is such a way, and with inotify it should
be acceptable. find does _not_ take that long, not even for git trees.

[EMAIL PROTECTED]:/data/l/linux$ time find . > /dev/null
0.04user 0.37system 11.50 (0m11.504s) elapsed 3.56%CPU

(If you wanted to be super-nice, you could introduce rename() helper
into glibc, that would do re-labeling synchronously, and only return
when it is done. All the nice applications call glibc anyway, and all
the exploits can't take advantage of it, because it is secure
already.).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Fri, 15 Jun 2007, Greg KH wrote:


On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:

Greg KH wrote:

On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:

Only case where attacker _can't_ be keeping file descriptors is newly
created files in recently moved tree. But as you already create files
with restrictive permissions, that's okay.

Yes, you may get some -EPERM during the tree move, but AA has that
problem already, see that "when madly moving trees we sometimes
construct path file never ever had".


Exactly.


You are remembering old behavior. The current AppArmor generates only
correct and consistent paths. If a process has an open file descriptor
to such a file, they will retain access to it, as we described here:
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf

Under the restorecon-alike proposal, you have a HUGE open race. This
post http://bugs.centos.org/view.php?id=1981 describes restorecon
running for 30 minutes relabeling a file system. That is so far from
acceptable that it is silly.


Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
only problem we have here, it isn't an issue.


how do you 'fix' the laws of physics?

the problem is that with a directory that contains lots of files below it 
you have to access all the files metadata to change the labels on it. it 
can take significant amounts of time to walk the entire three and change 
every file.



I can't think of a "real world" use of moving directory trees around
that this would come up in as a problem.

Consider this case: We've been developing a new web site for a month,
and testing it on the server by putting it in a different virtual
domain. We want to go live at some particular instant by doing an mv of
the content into our public HTML directory. We simultaneously want to
take the old web site down and archive it by moving it somewhere else.

Under the restorecon proposal, the web site would be horribly broken
until restorecon finishes, as various random pages are or are not
accessible to Apache.


Usually you don't do that by doing a 'mv' otherwise you are almost
guaranteed stale and mixed up content for some period of time, not to
mention the issues surrounding paths that might be messed up.


on the contrary, useing 'mv' is by far the cleanest way to do this.

mv htdocs htdocs.old;mv htdocs.new htdocs

this makes two atomic changes to the filesystem, but can generate 
thousands to millions of permission changes as a result.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> Greg KH wrote:
> > On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> >   
>  * Renamed Directory trees: The above problem is compounded with
>    directory trees. Changing the name at the top of a large, bushy
>    tree can require instant relabeling of millions of files.
>  
> >>> Same daemon can do this.  And yes, it might take a ammount of time, but
> >>> the times that this happens in "real-life" on a "production" server is
> >>> quite small, if at all.
> >>>   
> >> And now, if you move a tree, there will be old labels for a while. But
> >> this does not matter, because attacker could be keeping file
> >> descriptors.
> >> 
> > Agreed.
> >   
> We have built a label-based AA prototype. It fails because there is no
> reasonable way to address the tree renaming problem.

How does inotify not work here?  You are notified that the tree is
moved, your daemon goes through and relabels things as needed.  In the
meantime, before the re-label happens, you might have the wrong label on
things, but "somehow" SELinux already handles this, so I think you
should be fine.

> >> Only case where attacker _can't_ be keeping file descriptors is newly
> >> created files in recently moved tree. But as you already create files
> >> with restrictive permissions, that's okay.
> >>
> >> Yes, you may get some -EPERM during the tree move, but AA has that
> >> problem already, see that "when madly moving trees we sometimes
> >> construct path file never ever had".
> >> 
> > Exactly.
> >   
> You are remembering old behavior. The current AppArmor generates only
> correct and consistent paths. If a process has an open file descriptor
> to such a file, they will retain access to it, as we described here:
> http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
> 
> Under the restorecon-alike proposal, you have a HUGE open race. This
> post http://bugs.centos.org/view.php?id=1981 describes restorecon
> running for 30 minutes relabeling a file system. That is so far from
> acceptable that it is silly.

Ok, so we fix it.  Seriously, it shouldn't be that hard.  If that's the
only problem we have here, it isn't an issue.

> Of course, this depends on the system in question, but restorecon will
> necessarily need to traverse whatever portions of the filesystem that
> have changed, which can be quite a long time indeed. Any race condition
> measured in minutes is a very serious issue.

Agreed, so we fix that.  There are ways to speed those kinds of things
up quite a bit, and I imagine since the default SELinux behavior doesn't
use restorecon in this kind of use-case, no one has spent the time to do
the work.

> > I can't think of a "real world" use of moving directory trees around
> > that this would come up in as a problem.
> Consider this case: We've been developing a new web site for a month,
> and testing it on the server by putting it in a different virtual
> domain. We want to go live at some particular instant by doing an mv of
> the content into our public HTML directory. We simultaneously want to
> take the old web site down and archive it by moving it somewhere else.
> 
> Under the restorecon proposal, the web site would be horribly broken
> until restorecon finishes, as various random pages are or are not
> accessible to Apache.

Usually you don't do that by doing a 'mv' otherwise you are almost
guaranteed stale and mixed up content for some period of time, not to
mention the issues surrounding paths that might be messed up.

> In a smaller scale example, I want to share some files with a friend. I
> can't be bothered to set up a proper access control system, so I just mv
> the files to ~crispin/public_html/lookitme and in IRC say "get it now,
> going away in 10 minutes" and then move it out again. Yes, you can
> manually address this by running "restorecon ~crispin/public_html". But
> AA does this automatically without having to run any commands.

I'm saying that the daemon will automatically do it for you, you don't
have to do anything on your own.

> You could get restorecon to do this automatically by using inotify.

Yes.

> But to make it as general and transparent as AA is now, you would have
> to run inotify on every directory in the system, with consequences for
> kernel memory and performance.

What "kernel memory and performance" issues are there?  Your SLED
machine already has inotify running on every directory in the system
today, and you don't seem to have noticed that :)

> This problem does not exist for SELinux, because SELinux does not expect
> access to change based on file names.

Agreed.

> This problem does not exist in the proposed AA implementation, because
> the patch makes the access decision based on the current name of the
> file, so it doesn't have a consistency problem between the file and its
> label; there is no label.

No, that's not the issue here.  The 

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 05:42:08PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
> 
> > > Or just create the files with restrictive labels by default. That way
> > > you "fail closed".
> > 
> > From my limited knowledge of SELinux, this is the default today so this
> > would happen by default.  Anyone with more SELinux experience want to
> > verify or fix my understanding of this?
> 
> This is entirely controllable via policy.  That is, you specify that newly 
> create files are labeled to something safe (enforced atomically at the 
> kernel level), and then your userland relabeler would be invoked via 
> inotify to relabel based on your userland pathname specification.
> 
> This labeling policy can be as granular as you wish, from the entire 
> filesystem to a single file.  It can also be applied depending on the 
> process which created the file and the directory its created in, ranging 
> from all processes and all directories, to say, just those running as 
> user_t in directories labeled as public_html_t (or whatever).

Oh great, then things like source code control systems would have no
problems with new files being created under them, or renaming whole
trees.

So, so much for the "it's going to be too slow re-labeling everything"
issue, as it's not even required for almost all situations :)

thanks for letting us know.

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

> > Yes, you may get some -EPERM during the tree move, but AA has that
> > problem already, see that "when madly moving trees we sometimes
> > construct path file never ever had".
> 
> Pavel, please focus on the current AppArmor implementation. You're
> remembering a flaw with a previous version of AppArmor. The pathnames
> constructed with the current version of AppArmor are consistent and
> correct.

Ok, I did not know that this got fixed.

How do you do that? Hold a lock preventing renames for a whole time
you walk from file to the root of filesystem?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Seth Arnold]

On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Yes, you may get some -EPERM during the tree move, but AA has that
> problem already, see that "when madly moving trees we sometimes
> construct path file never ever had".

Pavel, please focus on the current AppArmor implementation. You're
remembering a flaw with a previous version of AppArmor. The pathnames
constructed with the current version of AppArmor are consistent and
correct.

Thanks.


pgps7yFSK4Br7.pgp
Description: PGP signature

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Crispin Cowan]

Greg KH wrote:
> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
>   
 * Renamed Directory trees: The above problem is compounded with
   directory trees. Changing the name at the top of a large, bushy
   tree can require instant relabeling of millions of files.
 
>>> Same daemon can do this.  And yes, it might take a ammount of time, but
>>> the times that this happens in "real-life" on a "production" server is
>>> quite small, if at all.
>>>   
>> And now, if you move a tree, there will be old labels for a while. But
>> this does not matter, because attacker could be keeping file
>> descriptors.
>> 
> Agreed.
>   
We have built a label-based AA prototype. It fails because there is no
reasonable way to address the tree renaming problem.

>> Only case where attacker _can't_ be keeping file descriptors is newly
>> created files in recently moved tree. But as you already create files
>> with restrictive permissions, that's okay.
>>
>> Yes, you may get some -EPERM during the tree move, but AA has that
>> problem already, see that "when madly moving trees we sometimes
>> construct path file never ever had".
>> 
> Exactly.
>   
You are remembering old behavior. The current AppArmor generates only
correct and consistent paths. If a process has an open file descriptor
to such a file, they will retain access to it, as we described here:
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf

Under the restorecon-alike proposal, you have a HUGE open race. This
post http://bugs.centos.org/view.php?id=1981 describes restorecon
running for 30 minutes relabeling a file system. That is so far from
acceptable that it is silly.

Of course, this depends on the system in question, but restorecon will
necessarily need to traverse whatever portions of the filesystem that
have changed, which can be quite a long time indeed. Any race condition
measured in minutes is a very serious issue.

> I can't think of a "real world" use of moving directory trees around
> that this would come up in as a problem.
Consider this case: We've been developing a new web site for a month,
and testing it on the server by putting it in a different virtual
domain. We want to go live at some particular instant by doing an mv of
the content into our public HTML directory. We simultaneously want to
take the old web site down and archive it by moving it somewhere else.

Under the restorecon proposal, the web site would be horribly broken
until restorecon finishes, as various random pages are or are not
accessible to Apache.

In a smaller scale example, I want to share some files with a friend. I
can't be bothered to set up a proper access control system, so I just mv
the files to ~crispin/public_html/lookitme and in IRC say "get it now,
going away in 10 minutes" and then move it out again. Yes, you can
manually address this by running "restorecon ~crispin/public_html". But
AA does this automatically without having to run any commands.

You could get restorecon to do this automatically by using inotify. But
to make it as general and transparent as AA is now, you would have to
run inotify on every directory in the system, with consequences for
kernel memory and performance.

This problem does not exist for SELinux, because SELinux does not expect
access to change based on file names.

This problem does not exist in the proposed AA implementation, because
the patch makes the access decision based on the current name of the
file, so it doesn't have a consistency problem between the file and its
label; there is no label.

The problem is induced by trying to emulate AA on top of SELinux. They
don't fit well together. AA fits much better with LSM, which is the
reason LSM exists.

>   Maybe a source code control
> system might have this issue for the server, but in a second or two
> everything would be working again as the new files would be relabled
> correctly.
>   
Try an hour or two for a large source code repository. Its linear in the
number of files, and several hundred thousand files would take a while
to relabel. A large GIT tree would be particularly painful because of
the very large number of files.

> Can anyone else see a problem with this that I'm just being foolish and
> missing?
>   
It is not foolish. The label idea is so attractive that last September
from discussions with Arjan we actually thought it was the preferred
implementation. However, what we've been saying over and over again is
that we *tried* this, and it *doesn't* work at the implementation level.
There is no good answer, restorecon is an ugly kludge, and so this
seductive approach turns out to be a dead end.

Caveat: I am *not* saying that labels in general are bad, just that they
are a bad way to emulate the AppArmor model. And yes, I am working on a
model paper that is more abstract than Andreas' paper
,
but that takes time.

Then

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Casey Schaufler]

--- Greg KH <[EMAIL PROTECTED]> wrote:

> On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > 
> > Yup, I see that once you accept the notion that it is OK for a
> > file to be misslabeled for a bit and that having a fixxerupperd
> > is sufficient it all falls out.
> > 
> > My point is that there is a segment of the security community
> > that had not found this acceptable, even under the conditions
> > outlined. If it meets your needs, I say run with it.
> 
> If that segment feels that way, then I imagine AA would not meet their
> requirements today due to file handles and other ways of passing around
> open files, right?

That segment is itself divided (think the "Judean Peoples Front"
and the "Peoples Front of Judea") on many issues, but as it has
always put correctness over ease of use I would expect AppArmor to
have a tough roe to hoe. There are other segments for which AppArmor
may well be appealing, and those segments have always been much
larger than Judea.

> So, would SELinux today (without this AA-like daemon) fit the
> requirements of this segment?

The JPF is head over heels in love with SELinux, restorecond and all.
The PFJ has some issues, but will most likely go along with the JPF
in part because the JPF is bringing the beer and besides, what are
their alternatives today? The PJF ("that's him, over there") is still
stunned by some of what SELinux accepts as normal (restorecond, 400,000
line "policy" definitions with embedded wildcards) and spends a lot
of time chanting the TCB Principle in hopes that it will help, but
no lightning strikes from above to date.

But you knew that. I'm an advocate of making a variety of alternates
available which is why I had originally proposed the authoritative
hooks version of the LSM and why I don't believe in rolling every
possible security facility into SELinux. I also believe in warning
people of pitfalls before they've impaled themselves on the spikes,
but some people gotta have the experience. Just trying to help.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Karl MacMillan]

On Fri, 2007-06-15 at 14:44 -0700, Greg KH wrote:
> On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> > On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > > > 
> > > > Yup, I see that once you accept the notion that it is OK for a
> > > > file to be misslabeled for a bit and that having a fixxerupperd
> > > > is sufficient it all falls out.
> > > > 
> > > > My point is that there is a segment of the security community
> > > > that had not found this acceptable, even under the conditions
> > > > outlined. If it meets your needs, I say run with it.
> > > 
> > > If that segment feels that way, then I imagine AA would not meet their
> > > requirements today due to file handles and other ways of passing around
> > > open files, right?
> > > 
> > > So, would SELinux today (without this AA-like daemon) fit the
> > > requirements of this segment?
> > > 
> > 
> > Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
> > using the features of SELinux where appropriate.
> 
> Great, but is there the requirement in the CC stuff such that this type
> of "delayed re-label" that an AA-like daemon would need to do cause that
> model to not be able to be certified like your SELinux implementation
> is?
> 

There are two things:

1) relabeling (non-tranquility) is very problematic in general because
revocation is hard (and non-solved in Linux). So you would have to
address concerns about that.

2) Whether this would pass certification depends on a lot of factors
(like the specific requirements - CC is just a process not a single set
of requirements). I don't know enough to really guess.

More to the point, though, the requirements in those documents are
outdated at best. I don't think it is worth worrying over.

> As I'm guessing the default "label" for things like this already work
> properly for SELinux, I figure we should be safe, but I don't know those
> requirements at all.
> 

Probably not - you would likely want it to be a label that can't be read
or written by anything, only relabeled by the daemon.

Karl


-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > > 
> > > Yup, I see that once you accept the notion that it is OK for a
> > > file to be misslabeled for a bit and that having a fixxerupperd
> > > is sufficient it all falls out.
> > > 
> > > My point is that there is a segment of the security community
> > > that had not found this acceptable, even under the conditions
> > > outlined. If it meets your needs, I say run with it.
> > 
> > If that segment feels that way, then I imagine AA would not meet their
> > requirements today due to file handles and other ways of passing around
> > open files, right?
> > 
> > So, would SELinux today (without this AA-like daemon) fit the
> > requirements of this segment?
> > 
> 
> Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
> using the features of SELinux where appropriate.

Great, but is there the requirement in the CC stuff such that this type
of "delayed re-label" that an AA-like daemon would need to do cause that
model to not be able to be certified like your SELinux implementation
is?

As I'm guessing the default "label" for things like this already work
properly for SELinux, I figure we should be safe, but I don't know those
requirements at all.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[James Morris]

On Fri, 15 Jun 2007, Greg KH wrote:

> > Or just create the files with restrictive labels by default. That way
> > you "fail closed".
> 
> From my limited knowledge of SELinux, this is the default today so this
> would happen by default.  Anyone with more SELinux experience want to
> verify or fix my understanding of this?

This is entirely controllable via policy.  That is, you specify that newly 
create files are labeled to something safe (enforced atomically at the 
kernel level), and then your userland relabeler would be invoked via 
inotify to relabel based on your userland pathname specification.

This labeling policy can be as granular as you wish, from the entire 
filesystem to a single file.  It can also be applied depending on the 
process which created the file and the directory its created in, ranging 
from all processes and all directories, to say, just those running as 
user_t in directories labeled as public_html_t (or whatever).



- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Karl MacMillan]

On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > 
> > Yup, I see that once you accept the notion that it is OK for a
> > file to be misslabeled for a bit and that having a fixxerupperd
> > is sufficient it all falls out.
> > 
> > My point is that there is a segment of the security community
> > that had not found this acceptable, even under the conditions
> > outlined. If it meets your needs, I say run with it.
> 
> If that segment feels that way, then I imagine AA would not meet their
> requirements today due to file handles and other ways of passing around
> open files, right?
> 
> So, would SELinux today (without this AA-like daemon) fit the
> requirements of this segment?
> 

Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
using the features of SELinux where appropriate.

Karl



-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> 
> Yup, I see that once you accept the notion that it is OK for a
> file to be misslabeled for a bit and that having a fixxerupperd
> is sufficient it all falls out.
> 
> My point is that there is a segment of the security community
> that had not found this acceptable, even under the conditions
> outlined. If it meets your needs, I say run with it.

If that segment feels that way, then I imagine AA would not meet their
requirements today due to file handles and other ways of passing around
open files, right?

So, would SELinux today (without this AA-like daemon) fit the
requirements of this segment?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Hi!
> 
> And before you scream "races", take a look. It does not actually add
> them:

Hey, I never screamed that at all, in fact, I completly agree with you
:)

> > > > I agree that the in-kernel implementation could use different 
> > > > abstractions 
> > > > than user-space, provided that the underlying implementation details 
> > > > can be 
> > > > hidden well enough. The key phrase here is "if possible", and in fact 
> > > > "if 
> > > > possible" is much too strong: very many things in software are 
> > > > possible, 
> > > > including user-space drives and a stable kernel module ABI. Some things 
> > > > make 
> > > > sense; others are genuinely bad ideas while still possible.
> > > >   
> > > In particular, to layer AppArmor on top of SELinux, the following
> > > problems must be addressed:
> > > 
> > > * New files: when a file is created, it is labeled according to the
> > >   type of the creating process and the type of the parent directory.
> > >   Applications can also use libselinux to use application logic to
> > >   relabel the file, but that is not 'mandatory' policy, and fails in
> > >   cases like cp and mv. AppArmor lets you create a policy that e..g
> > >   says "/home/*/.plan r" to permit fingerd to read everyone's .plan
> > >   file, should it ever exist, and you cannot emulate that with 
> > > SELinux.
> > 
> > A daemon using inotify can "instantly"[1] detect this and label the file
> > properly if it shows up.
> 
> Or just create the files with restrictive labels by default. That way
> you "fail closed".

>From my limited knowledge of SELinux, this is the default today so this
would happen by default.  Anyone with more SELinux experience want to
verify or fix my understanding of this?

> > > * Renamed Files: Renaming a file changes the policy with respect to
> > >   that file in AA. To emulate this in SELinux, you would have to
> > >   have a way to instantly re-label the file upon rename.
> > 
> > Same daemon can do the re-label.
> 
> ...and no, race there is not important. Attacker may have opened the
> file under old name and is keeping open file descriptor. So this does
> not add a new race relative to AA.

Agreed.

> > > * Renamed Directory trees: The above problem is compounded with
> > >   directory trees. Changing the name at the top of a large, bushy
> > >   tree can require instant relabeling of millions of files.
> > 
> > Same daemon can do this.  And yes, it might take a ammount of time, but
> > the times that this happens in "real-life" on a "production" server is
> > quite small, if at all.
> 
> And now, if you move a tree, there will be old labels for a while. But
> this does not matter, because attacker could be keeping file
> descriptors.

Agreed.

> Only case where attacker _can't_ be keeping file descriptors is newly
> created files in recently moved tree. But as you already create files
> with restrictive permissions, that's okay.
> 
> Yes, you may get some -EPERM during the tree move, but AA has that
> problem already, see that "when madly moving trees we sometimes
> construct path file never ever had".

Exactly.

I can't think of a "real world" use of moving directory trees around
that this would come up in as a problem.  Maybe a source code control
system might have this issue for the server, but in a second or two
everything would be working again as the new files would be relabled
correctly.

Can anyone else see a problem with this that I'm just being foolish and
missing?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Casey Schaufler]

--- Stephen Smalley <[EMAIL PROTECTED]> wrote:

> On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> > --- Greg KH <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > > A daemon using inotify can "instantly"[1] detect this and label the file
> > > properly if it shows up.
> > 
> > In our 1995 B1 evaluation of Trusted Irix we were told in no
> > uncertain terms that such a solution was not acceptable under
> > the TCSEC requirements. Detection and relabel on an unlocked
> > object creates an obvious window for exploitation. We were told
> > that such a scheme would be considered a design flaw.
> > 
> > I understand that some of the Common Criteria labs are less
> > aggressive regarding chasing down these issues than the NCSC
> > teams were. It might not prevent an evaluation from completing
> > today. It is still hard to explain why it's ok to have a file
> > that's labeled incorrectly _even briefly_. It is the systems
> > job to ensure that that does not happen.
> 
> Um, Casey, he is talking about how to emulate AppArmor behavior on a
> label-based system like SELinux,

Yes. What I'm saying (or trying to) is that such an implementation
would be flawed by design.

> not meeting B1 or LSPP or anything like that
> (which AppArmor can't do regardless).

We're not talking about an implementation based on AppArmor. As
you point out, we're talking about implementing name based access
control as an extension of SELinux.

> As far as general issue
> goes, if your policy is configured such that the new file gets the most
> restrictive label possible at creation time and then the daemon relabels
> it to a less restrictive label if appropriate, then there is no actual
> window of exposure.

Is it general practice to configure policy such that "the new file gets
the most restrictive label possible at creation time"? I confess that
my understanding of the current practice in policy generation is based
primarily on a shouted conversation in a crowded Irish pub.

> Also, there is such a daemon, restorecond, in SELinux (policycoreutils)
> although we avoid relying on it for anything security-critical
> naturally.

Yes, I am aware of restorecond. I find the need for restorecond troubling.

> And one could introduce the named type transition concept
> that has been discussed in this thread without much difficulty to
> selinux.

Yup, I see that once you accept the notion that it is OK for a
file to be misslabeled for a bit and that having a fixxerupperd
is sufficient it all falls out.

My point is that there is a segment of the security community
that had not found this acceptable, even under the conditions
outlined. If it meets your needs, I say run with it.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Pavel Machek]

Hi!

And before you scream "races", take a look. It does not actually add
them:

> > > I agree that the in-kernel implementation could use different 
> > > abstractions 
> > > than user-space, provided that the underlying implementation details can 
> > > be 
> > > hidden well enough. The key phrase here is "if possible", and in fact "if 
> > > possible" is much too strong: very many things in software are possible, 
> > > including user-space drives and a stable kernel module ABI. Some things 
> > > make 
> > > sense; others are genuinely bad ideas while still possible.
> > >   
> > In particular, to layer AppArmor on top of SELinux, the following
> > problems must be addressed:
> > 
> > * New files: when a file is created, it is labeled according to the
> >   type of the creating process and the type of the parent directory.
> >   Applications can also use libselinux to use application logic to
> >   relabel the file, but that is not 'mandatory' policy, and fails in
> >   cases like cp and mv. AppArmor lets you create a policy that e..g
> >   says "/home/*/.plan r" to permit fingerd to read everyone's .plan
> >   file, should it ever exist, and you cannot emulate that with SELinux.
> 
> A daemon using inotify can "instantly"[1] detect this and label the file
> properly if it shows up.

Or just create the files with restrictive labels by default. That way
you "fail closed".

> > * Renamed Files: Renaming a file changes the policy with respect to
> >   that file in AA. To emulate this in SELinux, you would have to
> >   have a way to instantly re-label the file upon rename.
> 
> Same daemon can do the re-label.

...and no, race there is not important. Attacker may have opened the
file under old name and is keeping open file descriptor. So this does
not add a new race relative to AA.

> > * Renamed Directory trees: The above problem is compounded with
> >   directory trees. Changing the name at the top of a large, bushy
> >   tree can require instant relabeling of millions of files.
> 
> Same daemon can do this.  And yes, it might take a ammount of time, but
> the times that this happens in "real-life" on a "production" server is
> quite small, if at all.

And now, if you move a tree, there will be old labels for a while. But
this does not matter, because attacker could be keeping file
descriptors.

Only case where attacker _can't_ be keeping file descriptors is newly
created files in recently moved tree. But as you already create files
with restrictive permissions, that's okay.

Yes, you may get some -EPERM during the tree move, but AA has that
problem already, see that "when madly moving trees we sometimes
construct path file never ever had".

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> --- Greg KH <[EMAIL PROTECTED]> wrote:
> 
> 
> > A daemon using inotify can "instantly"[1] detect this and label the file
> > properly if it shows up.
> 
> In our 1995 B1 evaluation of Trusted Irix we were told in no
> uncertain terms that such a solution was not acceptable under
> the TCSEC requirements. Detection and relabel on an unlocked
> object creates an obvious window for exploitation. We were told
> that such a scheme would be considered a design flaw.
> 
> I understand that some of the Common Criteria labs are less
> aggressive regarding chasing down these issues than the NCSC
> teams were. It might not prevent an evaluation from completing
> today. It is still hard to explain why it's ok to have a file
> that's labeled incorrectly _even briefly_. It is the systems
> job to ensure that that does not happen.

Um, Casey, he is talking about how to emulate AppArmor behavior on a
label-based system like SELinux, not meeting B1 or LSPP or anything like
that (which AppArmor can't do regardless).  As far as general issue
goes, if your policy is configured such that the new file gets the most
restrictive label possible at creation time and then the daemon relabels
it to a less restrictive label if appropriate, then there is no actual
window of exposure.

Also, there is such a daemon, restorecond, in SELinux (policycoreutils)
although we avoid relying on it for anything security-critical
naturally.  And one could introduce the named type transition concept
that has been discussed in this thread without much difficulty to
selinux.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Casey Schaufler]

--- Greg KH <[EMAIL PROTECTED]> wrote:


> A daemon using inotify can "instantly"[1] detect this and label the file
> properly if it shows up.

In our 1995 B1 evaluation of Trusted Irix we were told in no
uncertain terms that such a solution was not acceptable under
the TCSEC requirements. Detection and relabel on an unlocked
object creates an obvious window for exploitation. We were told
that such a scheme would be considered a design flaw.

I understand that some of the Common Criteria labs are less
aggressive regarding chasing down these issues than the NCSC
teams were. It might not prevent an evaluation from completing
today. It is still hard to explain why it's ok to have a file
that's labeled incorrectly _even briefly_. It is the systems
job to ensure that that does not happen.


Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Thu, Jun 14, 2007 at 05:18:43PM -0700, [EMAIL PROTECTED] wrote:
>  On Thu, 14 Jun 2007, Jack Stone wrote:
> 
> > [EMAIL PROTECTED] wrote:
> >> On Sun, 10 Jun 2007, Pavel Machek wrote:
> >>> But you have that regex in _user_ space, in a place where policy
> >>> is loaded into kernel.
> >>
> >> then the kernel is going to have to call out to userspace every time a
> >> file is created or renamed and the policy is going to be enforced
> >> incorrectly until userspace finished labeling/relabeling whatever is
> >> moved. building this sort of race condigion for security into the kernel
> >> is highly questionable at best.
> >>
> >>> AA has regex parser in _kernel_ space, which is very wrong.
> >>
> >> see Linus' rants about why it's not automaticaly the best thing to move
> >> functionality into userspace.
> >>
> >> remember that the files covered by an AA policy can change as files are
> >> renamed. this isn't the case with SELinux so it doesn't have this sort
> >> of problem.
> >
> > How about using the inotify interface on / to watch for file changes and
> > updating the SELinux policies on the fly. This could be done from a
> > userspace daemon and should require minimal SELinux changes.
> >
> > The only possible problems I can see are the (hopefully) small gap
> > between the file change and updating the policy and the performance
> > problems of watching the whole system for changes.
> 
>  as was mentioned by someone else, if you rename a directory this can result 
>  in millions of files that need to be relabeled (or otherwise have the policy 
>  changed for them)
> 
>  that can take a significant amount of time to do.

So?  The number of "real-world" times that this happens is probably
non-existant on a "production" server.  And if you are doing this on a
developer machine, then yes, there might be some slow-down, but no more
than is currently happening with tools like Beagle that people are
already shipping and supporting in "enterprise" solutions.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Greg KH]

On Sun, Jun 10, 2007 at 10:09:18AM -0700, Crispin Cowan wrote:
> Andreas Gruenbacher wrote:
> > On Saturday 09 June 2007 02:17, Greg KH wrote:
> >   
> >> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
> >> 
> >>> AppArmor is meant to be relatively easy to understand, manage, and
> >>>  customize, and introducing a labels layer wouldn't help these goals.
> >>>   
> >> Woah, that describes the userspace side of AA just fine, it means
> >> nothing when it comes to the in-kernel implementation. There is no 
> >> reason that you can't implement the same functionality using some
> >> totally different in-kernel solution if possible.
> >> 
> > I agree that the in-kernel implementation could use different abstractions 
> > than user-space, provided that the underlying implementation details can be 
> > hidden well enough. The key phrase here is "if possible", and in fact "if 
> > possible" is much too strong: very many things in software are possible, 
> > including user-space drives and a stable kernel module ABI. Some things 
> > make 
> > sense; others are genuinely bad ideas while still possible.
> >   
> In particular, to layer AppArmor on top of SELinux, the following
> problems must be addressed:
> 
> * New files: when a file is created, it is labeled according to the
>   type of the creating process and the type of the parent directory.
>   Applications can also use libselinux to use application logic to
>   relabel the file, but that is not 'mandatory' policy, and fails in
>   cases like cp and mv. AppArmor lets you create a policy that e..g
>   says "/home/*/.plan r" to permit fingerd to read everyone's .plan
>   file, should it ever exist, and you cannot emulate that with SELinux.

A daemon using inotify can "instantly"[1] detect this and label the file
properly if it shows up.

> * Renamed Files: Renaming a file changes the policy with respect to
>   that file in AA. To emulate this in SELinux, you would have to
>   have a way to instantly re-label the file upon rename.

Same daemon can do the re-label.

> * Renamed Directory trees: The above problem is compounded with
>   directory trees. Changing the name at the top of a large, bushy
>   tree can require instant relabeling of millions of files.

Same daemon can do this.  And yes, it might take a ammount of time, but
the times that this happens in "real-life" on a "production" server is
quite small, if at all.

> * New Policies: The SEEdit approach of compiling AA profiles into
>   SELinux labels involves computing the partition set of files, so
>   that each element of the partition set is unique, and corresponds
>   to all the policies that treat every file in the element
>   identically. If you create a new profile that touches *some* of
>   the files in such an element, then you have to split that
>   synthetic label, re-compute the partition set, and re-label the
>   file system.

Again, same daemon can handle this logic.

> * File Systems That Do Not Support Labels: The most important being
>   NFS3 and FAT. Because they do not support labels at all, SELinux
>   has to give you an all-or-nothing access control on the entire
>   remote volume. AA can give you nuanced access control in these
>   file systems.

SELinux already provides support for the whole mounted filesystem,
which, in real-life testing, seems to be quite sufficient.  Also, the
SELinux developers are working on some changes to make this a bit more
fine-grained.

See also Stephan's previous comments about NFSv3 client directories and
multiple views having the potential to cause a lot of havoc.

> You could support all of these features in SELinux, but only by adding
> an in-kernel file matching mechanism similar to AppArmor.

I don't think that is necessary at all, see above for why.

> It would basically load an AppArmor policy into the kernel, label
> files as they are brought from disk into the cache, and then use
> SELinux to do the access controls.

No, do the labeling in userspace with a daemon using inotify to handle
the changing of the files around.

Or has this whole idea of a daemon been disproved already with a
prototype somewhere that failed?  If not, a simple test app would not be
that hard to hack up.  Maybe I'll see if I can do it during the week of
June 24 :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[david]

On Thu, 14 Jun 2007, Jack Stone wrote:


[EMAIL PROTECTED] wrote:

On Sun, 10 Jun 2007, Pavel Machek wrote:

But you have that regex in _user_ space, in a place where policy
is loaded into kernel.


then the kernel is going to have to call out to userspace every time a
file is created or renamed and the policy is going to be enforced
incorrectly until userspace finished labeling/relabeling whatever is
moved. building this sort of race condigion for security into the kernel
is highly questionable at best.


AA has regex parser in _kernel_ space, which is very wrong.


see Linus' rants about why it's not automaticaly the best thing to move
functionality into userspace.

remember that the files covered by an AA policy can change as files are
renamed. this isn't the case with SELinux so it doesn't have this sort
of problem.


How about using the inotify interface on / to watch for file changes and
updating the SELinux policies on the fly. This could be done from a
userspace daemon and should require minimal SELinux changes.

The only possible problems I can see are the (hopefully) small gap
between the file change and updating the policy and the performance
problems of watching the whole system for changes.


as was mentioned by someone else, if you rename a directory this can 
result in millions of files that need to be relabeled (or otherwise have 
the policy changed for them)


that can take a significant amount of time to do.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Jack Stone]

[EMAIL PROTECTED] wrote:
> On Sun, 10 Jun 2007, Pavel Machek wrote:
>> But you have that regex in _user_ space, in a place where policy
>> is loaded into kernel.
> 
> then the kernel is going to have to call out to userspace every time a
> file is created or renamed and the policy is going to be enforced
> incorrectly until userspace finished labeling/relabeling whatever is
> moved. building this sort of race condigion for security into the kernel
> is highly questionable at best.
> 
>> AA has regex parser in _kernel_ space, which is very wrong.
> 
> see Linus' rants about why it's not automaticaly the best thing to move
> functionality into userspace.
> 
> remember that the files covered by an AA policy can change as files are
> renamed. this isn't the case with SELinux so it doesn't have this sort
> of problem.

How about using the inotify interface on / to watch for file changes and
 updating the SELinux policies on the fly. This could be done from a
userspace daemon and should require minimal SELinux changes.

The only possible problems I can see are the (hopefully) small gap
between the file change and updating the policy and the performance
problems of watching the whole system for changes.

Just my $0.02.

Jack
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Lars Marowsky-Bree]

On 2007-06-10T23:05:47, Pavel Machek <[EMAIL PROTECTED]> wrote:

> But you have that regex in _user_ space, in a place where policy
> is loaded into kernel.
> 
> AA has regex parser in _kernel_ space, which is very wrong.

That regex parser only applies user defined policy. The logical
connection between your two points doesn't exist.


Regards,
Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Stephen Smalley]

On Sat, 2007-06-09 at 00:03 +0200, Andreas Gruenbacher wrote:
> On Wednesday 06 June 2007 15:26, Stephen Smalley wrote:
> > - under AA, each file may have an arbitrary set of "labels" or
> > "policies" applied to it depending on what programs are accessing it and
> > what names are being used to reference it - there is no system view of
> > the subjects and objects and thus no way to identify the overall system
> > policy for a given file.
> 
> Look at it this way: under SELinux, the set of files that share a label forms 
> an equivalence class -- they are all treated identically by the system's 
> security policy. The rules in AppArmor profiles also define equivalence 
> classes in the sense that they partition the filesystem namespace into sets 
> of files that are treated identically, but this classification is not 
> explicit -- the entire rule base contributes to the classification. This 
> doesn't mean that there is not a global policy, just that the policy is 
> modeled differently. The equivalence classes are not directly obvious from 
> the AA profiles.

No, it really does mean that there is no global policy, and it goes
beyond "not directly obvious" to "can not be determined" from the AA
profiles.  You can't compose the set of AA profiles and say anything
useful, because they are written in terms of ambiguous and unstable
identifiers.  /a/b/c may refer to completely different objects in two
different profiles, or to the same object as /d/e/f in the same or
another profile.

> Contrast this with SEEdit, which compiles AA-style rules into labels (and 
> thus 
> equivalence classes). The resulting SELinux policy is a static snapshot that 
> cannot easily accommodate rule base changes, is more limited with respect to 
> new files (which would likely be fixable), and behaves differently in complex 
> ways with file renames. What's more, most likely the compiled policy will be 
> anywhere from very hard to impossible to analyze, so you pretty much lose on 
> all ends.

Just to clarify, you can change the allowed accesses from a given
subject to a given object without relabeling, just by changing the
policy allow rules; you only have to relabel the object in the case
where you want to distinguish that object from another object with the
same label for the same subject.  I think the new file situation could
be improved without any major change to the SELinux model, and am not
opposed to leveraging the component name there, as previously noted.  On
the file rename case, I think we have it right - access rights shouldn't
change automatically when a file is renamed, any more than DAC ownership
or file modes should.

> > - names are far less tranquil than labels.
> 
> If I'm getting things right, a tranquil system with respect to labels would 
> be 
> one that does not permit re-labeling, while a tranquil system with respect to 
> path names would be one that does not permit renaming. Both approaches would 
> buy greater analyzability with reduced usability, and both seem unrealistic 
> to me. SELinux and AppArmor evidently have different goals, and tranquility 
> is more important to SELinux.

Tranquility is important to correctness and understandability of policy;
if labels (or pathnames in your case) can change at any time, then you
have the problems of revocation of access (impractical to completely
implement in Linux) and your effective policy now varies over time, so
you have to consider time as a factor in your policy analysis.

> AppArmor is meant to be relatively easy to understand, manage, and customize, 
> and introducing a labels layer wouldn't help these goals. SELinux is 
> applicable in areas where AppArmor is not (e.g., MLS), but this comes at a 
> cost. For me the question is not SELinux or AppArmor, but if AppArmor's 
> security model is a good solution in common scenarios. In my opinion, 
> AppArmor is a better answer than SELinux in a number of scenarios. This gives 
> it value, nonwithstanding the fact that SELinux can be taken further.

I'd agree that we shouldn't try to emulate AA as it is on SELinux.  The
question is more of whether we can meet the higher level functionality
goals that make some people want to use AA via SELinux.  That requires
separating those goals from the implementation details of AA.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

[Sean]

On Mon, 11 Jun 2007 02:33:30 -0700 (PDT)
[EMAIL PROTECTED] wrote:

> Ok, you are proposing throwing out all the label handling that SELinux 
> does, including any caching. forgive me if I agree with the SELinux people 
> that this is a very bad idea.

Well presumably AA would be doing caching etc.. so that doesn't seem like
a problem.  The SELinux people seem to think that accepting AA into the
kernel and supporting path based security at all is a mistake.  I guess
I forgive you for agreeing with them ;)

> I thought the userspace component was what you were proposing instead of 
> doing the regex matching in the kernel. if this isn't it what exactly are 
> you proposing?

No.. i've said quite a few times now that i'm not talking about calling out
to userspace.  The entire discussion of regex matching is a completely
separate discussion.  It's either the right thing to do, or not.  But the
same issues in regard to regex matching apply whether AA is built on top
of SELinux or not.

> AA policies are defined in terms of regex expressions. you say that this 
> should be able to be done on top of SELinux somehow without changing the 
> policies. so somewhere, something needs to interpret the regex to see if 
> it matches the path. this needs to be either kernel code or userspace 
> code. you have ruled out kernel code and are now claiming that userspace 
> isn't needed.

For whatever it's worth, i'll repeat again.   The AA kernel extension would
be associating paths with labels (using regex, or not).  At that point all
policy decisions would be enforced by SELinux using standard SELinux policy
rules.   The SELinux policy would be a translated version of the AA policy
file.  The translation could of course happen in userland.

The net affect of all that... is that you get a version of SELinux which
can be configured with the user friendly AA policy file format.   And,
files won't need to carry around security labels with them.  I leave
the debate about whether that's a good idea in general to others.  But
from what i can tell, it's the only significant difference between
SELinux and AA.

Depending on the way it was implemented, its conceivable that users could
mix and match native SELinux policy with custom AA policies as they
saw fit.

Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html