I feel we have reached the stage where the questions/comments being
made are actually directly relevant to AppArmor. I'm afraid I cannot
proceed any further now because I am not a security expert.
I would like to summarise what I think are the key points that you
have raised, and hope that someone who has a deeper understanding of
these things might answer them, or point to answers.
1/ Does AppArmor's primary mechanism of confining an application to a
superset of it's expected behaviour actually achieve its secondary
gaol of protecting data?
Possibly it would be better to ask "When does ..." as I think it is
easy to imagine application/profile pairs that clearly cannot allow
harm, and application/profile pairs that clearly could allow harm.
2/ What advantages does AppArmor provide over techniques involving
virtualisation or gaol mechanisms? Are these advantages worth
while?
3/ Is AppArmour's approach of using d_path to get a filename from a
dentry valid and acceptable? If not, how can it get a path? Can
suitable hooks be provided so that AppArmor can get a path in an
acceptable way at the times when that is meaningful?
I believe that these are all good questions. The last one is the only
one that it really relevant to linux-kernel I believe, however answers
to the first two might tell us how important it is to answer that last
one.
Thanks for your input.
NeilBrown
.... yes, I am top posting. The mail I am responding to is below. I
have not added any commentary in there but have left it for easy
reference so you, dear readers, can decide for yourself whether the
questions I have provided above are relevant to the preceding
discussion.
On Tuesday April 25, [email protected] wrote:
> On Tue, 2006-04-25 at 18:10 +1000, Neil Brown wrote:
> > But objects aren't the point. Paths are.
> > The primary goal of AppArmor isn't to protect objects.
>
> Ok, please document this throughout all AppArmor documentation and
> literature. It will be a source of great encouragement to users.
>
> > That is
> > secondary. The primary goal is to stop applications from
> > doing things that they weren't intended to do. i.e. it is to watch
> > their behaviour and make sure it doesn't deviate from what is
> > intended.
>
> What is intended goes beyond what names are used - it involves the
> actual objects. When /bin/su asks to open /etc/shadow, it wants the
> real system shadow password file, not just any old file to
> which /etc/shadow might happen to resolve. Further, even at this
> "primary" goal, AppArmor does a poor job wrt to already existing
> virtualization or jail mechanisms AFAICS.
>
> > This will largely have the effect of protecting data, as protecting
> > data is the intended secondary effect of AppArmor's primary mechanism
> > which is behaviour control.
>
> No, it won't protect the data. You can't have it both ways. Either you
> are only controlling the use of paths and not concerned with the objects
> (if so, please document as such, but I can't imagine Crispin et al
> admitting to such a position), or you are controlling the objects and
> thus protecting the data.
>
> > I think this text is fairly vague, and could be taken to mean several
> > things.
> > I think the policies do define what resources can be accessed and does
> > it using names. "Anything with name X can be accessed". Note that
> > AppArmor profiles never say what cannot be accessed, only what can.
>
> Um, that's problematic then. If I can't determine what cannot be
> accessed, then I can never know whether I have achieved my protection
> goals.
>
> > In that sense they are not primarily protecting things so in a sense
> > they are not protecting any given file. Nevertheless the net result
> > is an increased level of data protection.
>
> No, only the appearance of it.
>
> > Maybe the documentation could be improved - that wouldn't be an
> > uncommon situation.
>
> Dollars to donuts that they won't be willing to document that AA doesn't
> protect objects in their documentation.
>
> > > If it isn't, then is anyone and everyone free to introduce other
> > > path-based mechanisms in the kernel in the future? Why has that been
> > > frowned upon in the past if there really isn't anything wrong with it?
> >
> > "path-based mechanisms" like open, unlink, mkdir, ....
> > There are plenty of these in the kernel.
>
> Pathname resolution is fine, obviously. Regenerating pathnames in the
> kernel and using them as part of your mechanism is...interesting. Don't
> confuse the userspace configuration and kernel-user interface with the
> internal mechanisms. Should inotify be calling d_path internally for
> reporting to userspace?
>
> > "path-based mechanisms" like "You cannot truncate a file named /etc/shadow"?
> > No, that would not be appropriate in the kernel as it is not well
> > defined.
>
> That is precisely what AppArmor does.
>
> > However AppArmor doesn't (or shouldn't) do this. It might say "You
> > cannot truncate a file that you found by looking up the name
> > /etc/shadow", and I think that would be a valid and useful thing to
> > do.
>
> AA doesn't even do that - as most of the LSM hooks don't get the
> vfsmount info propagated to them, they don't know what specific path
> your application took to the file.
>
> > It might not do what you want, but that all depends on what you
> > want. The things you can ask AppArmor to do are still useful and
> > meaningful even if they are not the things that you might ask SELinux
> > to do.
>
> I don't see why you wouldn't use a jail-style mechanism if that is what
> you want.
>
> --
> Stephen Smalley
> National Security Agency
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
