> >
> > In the inode_create() security operation and related functions pass
> > the path (vfsmount + dentry) to the parent directory instead of the
> > inode. AppArmor will need this.
>
> So you're once again switching vfs_ to a pass a vfsmount argument, this
> time hidden under struct path. It's really hard to grasp a "no"
> sometimes, isn't it? :)
I'm sorry Christoph, but have you considered the remote possibility,
that you and Al are both wrong on this one? Well, there's one
excercise for you.
If you haven't noticed, I don't take "no" for an answer, until I'm
sufficiently convinced that there's a better way. In this case I
haven't heard a solution, that is remotely close in cleanliness to
what I've proposed. And also please note that "not merging apparmor"
is _not_ the answer, however much you would like that to be. So
please try harder to find an alternative, and then I'll listen.
Miklos
On Sun, Jun 01, 2008 at 10:52:33PM +0200, Miklos Szeredi wrote:
> If you haven't noticed, I don't take "no" for an answer,
And now please tell us step 2 in your secret plan to win friends and
influence.
> > If you haven't noticed, I don't take "no" for an answer,
>
> And now please tell us step 2 in your secret plan to win friends and
> influence.
WTF are you getting at? You think kernel development is about
boot-licking instead of standing by your technical arguments? What
have you been smoking lately?
I maintain, that moving lsm hooks into callers is insane. And that's
*the* sanest alternative that anybody has been able to come up with to
passing down vfsmounts into the vfs.
So again, can you offer an alternative?
I *am* genuinely interested, so any ideas from anybody wanting to help
resolve this issue are welcome.
Thanks,
Miklos
On Mon, Jun 02, 2008 at 09:02:14AM +0200, Miklos Szeredi wrote:
> > > If you haven't noticed, I don't take "no" for an answer,
> >
> > And now please tell us step 2 in your secret plan to win friends and
> > influence.
>
> WTF are you getting at? You think kernel development is about
> boot-licking instead of standing by your technical arguments? What
> have you been smoking lately?
No licking required :) But running against a wall continuously and
pissing off the people working in that area and maintainer is generally
not the smartest idea :)
> So again, can you offer an alternative?
Just give up on this dumb idea completely.
> > So again, can you offer an alternative?
>
> Just give up on this dumb idea completely.
You mean apparmor? I've already told you, that's not the answer. Go
up 4 mails and read again.
You act like a happy prince of VFS, but let me tell you one thing,
there's only one king in this kingdom of Linux, and that's Linus
Torvalds I. And our wise king already said that apparmor can come, so
the question is not "if" but "how".
If you don't want to help, that's a pity, but of course I don't want
to (and can't) force you. I can understand if personally you don't
think this is a good idea, and don't want to have anything to do with
it. In that case I can leave you off the CC's for the parts which are
not just generic VFS cleanups but explicitly towards apparmor
integration. Would that suit you?
Thanks,
Miklos
On Mon, Jun 02, 2008 at 11:32:44AM +0200, Miklos Szeredi wrote:
> You act like a happy prince of VFS, but let me tell you one thing,
> there's only one king in this kingdom of Linux, and that's Linus
> Torvalds I. And our wise king already said that apparmor can come, so
> the question is not "if" but "how".
>
> If you don't want to help, that's a pity, but of course I don't want
> to (and can't) force you. I can understand if personally you don't
> think this is a good idea, and don't want to have anything to do with
> it. In that case I can leave you off the CC's for the parts which are
> not just generic VFS cleanups but explicitly towards apparmor
> integration. Would that suit you?
No, and Agenda doesn't make these patches any better.
> > You act like a happy prince of VFS, but let me tell you one thing,
> > there's only one king in this kingdom of Linux, and that's Linus
> > Torvalds I. And our wise king already said that apparmor can come, so
> > the question is not "if" but "how".
> >
> > If you don't want to help, that's a pity, but of course I don't want
> > to (and can't) force you. I can understand if personally you don't
> > think this is a good idea, and don't want to have anything to do with
> > it. In that case I can leave you off the CC's for the parts which are
> > not just generic VFS cleanups but explicitly towards apparmor
> > integration. Would that suit you?
>
> No,
So shall I leave you _on_ the CC's then?
> and Agenda doesn't make these patches any better.
Umm, what's wrong with the patches then? What exactly do they break?
How do they make the kernel bigger and slower? How do they make the
code less readable?
These patches fix several issues raised at previous submissions:
- passing NULL vfsmounts
- using nameidata
- using extra stack for vfsmount argument
So, it seems to me that there's in fact no issues remaining and the
best excuse you can come up with is that it's a dumb idea. Well,
that's not a very imressive technical argument IMNSHO.
Miklos
On Monday 02 June 2008 11:13:41 Christoph Hellwig wrote:
> On Mon, Jun 02, 2008 at 09:02:14AM +0200, Miklos Szeredi wrote:
> > So again, can you offer an alternative?
>
> Just give up on this dumb idea completely.
The AppArmor guys have really gone a long way in arguing their case, and all
discussions so far have ended in you decreeing that pathnames are bad at some
point. Thanks a lot for your constructive input on other areas of the code,
but could you please come up with technical arguments why pathnames are
bad this time?
Thanks a lot!
Andreas
On Mon, Jun 02, 2008 at 11:52:52AM +0200, Miklos Szeredi wrote:
> These patches fix several issues raised at previous submissions:
>
> - passing NULL vfsmounts
> - using nameidata
> - using extra stack for vfsmount argument
>
> So, it seems to me that there's in fact no issues remaining and the
> best excuse you can come up with is that it's a dumb idea. Well,
> that's not a very imressive technical argument IMNSHO.
Well, pathname based access control is a dumb idea, and we've been
through this N times. You've also been told that vfs_ routines should
remain without vfsmount, and no that's not a stack-related issue no idea
where that part came from.
> > These patches fix several issues raised at previous submissions:
> >
> > - passing NULL vfsmounts
> > - using nameidata
> > - using extra stack for vfsmount argument
> >
> > So, it seems to me that there's in fact no issues remaining and the
> > best excuse you can come up with is that it's a dumb idea. Well,
> > that's not a very imressive technical argument IMNSHO.
>
> Well, pathname based access control is a dumb idea, and we've been
> through this N times.
You think it's a dumb idea. Several major distros, which ship the
code, *despite* being out-of-tree, don't.
> You've also been told that vfs_ routines should
> remain without vfsmount,
Oh, I've been told. But valid technical reason given? No.
Such hand waving won't help your cause at all. It's time for you to
actually look at the patches and stat technical reasons why they are
wrong, or let them be included. Is it so hard to understand that the
decision to include apparmor is not in your hands?
You can argue against the concept of apparmor itself, but you better
argue with Crispin, because I'm quite clueless about that part. When
you've convinced him (and Linus (and Ubuntu, and SUSE, and Mandriva))
that apparmor is a stupid idea, then I'll give up. Good luck with
that!
Miklos
On Mon, Jun 2, 2008 at 1:55 PM, Miklos Szeredi <[email protected]> wrote:
> You can argue against the concept of apparmor itself, but you better
> argue with Crispin, because I'm quite clueless about that part. When
> you've convinced him (and Linus (and Ubuntu, and SUSE, and Mandriva))
> that apparmor is a stupid idea, then I'll give up. Good luck with
> that!
But then I guess you can just by-pass the VFS maintainers and send
your patches directly to Andrew/Linus. Good luck with that! :-)
> > You can argue against the concept of apparmor itself, but you better
> > argue with Crispin, because I'm quite clueless about that part. When
> > you've convinced him (and Linus (and Ubuntu, and SUSE, and Mandriva))
> > that apparmor is a stupid idea, then I'll give up. Good luck with
> > that!
>
> But then I guess you can just by-pass the VFS maintainers and send
> your patches directly to Andrew/Linus. Good luck with that! :-)
You know what? I do think I'd stand a better chance, than Christoph
convincing Crispin :)
But no, that's not what I want to do. I do think that the VFS
maintainers are intelligent poeple, who can be convinced that fighting
against apparmor is not going to help anyone, and get back to the
technical issues of "how".
Miklos
On Mon, Jun 02, 2008 at 09:02:14AM +0200, Miklos Szeredi wrote:
> I maintain, that moving lsm hooks into callers is insane. And that's
> *the* sanest alternative that anybody has been able to come up with to
> passing down vfsmounts into the vfs.
Not so. I showed how pathname-based security could be done *without*
passing vfsmounts down at all. Unfortunately, you weren't interested.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
> > I maintain, that moving lsm hooks into callers is insane. And that's
> > *the* sanest alternative that anybody has been able to come up with to
> > passing down vfsmounts into the vfs.
>
> Not so. I showed how pathname-based security could be done *without*
> passing vfsmounts down at all. Unfortunately, you weren't interested.
Umm, not sure what you are referring to. Could you please give a
pointer? I'm sure the apparmor developers would be more than
interested in such a scheme, if it does indeed work.
Thanks,
Miklos
> > > I maintain, that moving lsm hooks into callers is insane. And that's
> > > *the* sanest alternative that anybody has been able to come up with to
> > > passing down vfsmounts into the vfs.
> >
> > Not so. I showed how pathname-based security could be done *without*
> > passing vfsmounts down at all. Unfortunately, you weren't interested.
>
> Umm, not sure what you are referring to. Could you please give a
> pointer? I'm sure the apparmor developers would be more than
> interested in such a scheme, if it does indeed work.
Found it:
http://lkml.org/lkml/2008/4/9/98
I did not take part in that discussion and could not have been able to
contribute anyway. From a cursory read of the thread, the idea was
good, but not entirely applicable to apparmor. Or did I miss
something?
Thanks,
Miklos
On Mon, Jun 02, 2008 at 01:52:21PM +0200, Miklos Szeredi wrote:
> Found it:
>
> http://lkml.org/lkml/2008/4/9/98
>
> I did not take part in that discussion and could not have been able to
> contribute anyway. From a cursory read of the thread, the idea was
> good, but not entirely applicable to apparmor. Or did I miss
> something?
Sorry, I thought you were on the CC for that.
The conversation was somewhat unclear, at least in part because I'd
misunderstood the apparmour deny vs allow logic. It was also extremely
unhelpful when certain people decided to have a debate about path-name
based security. So let me try again.
The point is to resolve pathnames into dev_t + inode in the
context where the rule is set up. Then you can implement (say)
security_inode_permission() without needing to pass in a vfsmount -- all
you need are the inode->i_ino and inode->i_sb->s_dev to do a comparison.
Yes, if someone mounts /etc onto /etc2/ and has a rule to allow them to
access /etc/shadow, they will then be able to access /etc2/shadow as
well (which they weren't able to under previous apparmour). But I can't
think of a way that permits Something Bad to happen (since the contents
of the file could have been accessed through /etc/shadow *anyway*).
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Monday 02 June 2008 14:32:46 Matthew Wilcox wrote:
> The point is to resolve pathnames into dev_t + inode in the
> context where the rule is set up. Then you can implement (say)
> security_inode_permission() without needing to pass in a vfsmount -- all
> you need are the inode->i_ino and inode->i_sb->s_dev to do a comparison.
Without the vfsmount, when something is mounted in more than once place, you
cannot report which of the name aliases a process is accessing. This is
unacceptable; the logs would become unusable. With pathname-based, the
AppArmor and TOMOYO folks really mean pathname-based, not a hybrid pathname /
mount point model.
> Yes, if someone mounts /etc onto /etc2/ and has a rule to allow them to
> access /etc/shadow, they will then be able to access /etc2/shadow as
> well (which they weren't able to under previous apparmour). But I can't
> think of a way that permits Something Bad to happen (since the contents
> of the file could have been accessed through /etc/shadow *anyway*).
Yes, when a security policy specifies different permissions for the same
object on different paths, processes are of course limited to the least
restrictive of those paths.
One consequence of this is that pathname-based models must control who is
allowed to create aliases where, of course.
Andreas
On Mon, Jun 02, 2008 at 02:45:10PM +0200, Andreas Gruenbacher wrote:
> Without the vfsmount, when something is mounted in more than once place, you
> cannot report which of the name aliases a process is accessing. This is
> unacceptable; the logs would become unusable. With pathname-based, the
> AppArmor and TOMOYO folks really mean pathname-based, not a hybrid pathname /
> mount point model.
audit_getname manages to do this. You're just not thinking hard enough ;-)
> One consequence of this is that pathname-based models must control who is
> allowed to create aliases where, of course.
Absolutely.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Monday 02 June 2008 14:49:06 Matthew Wilcox wrote:
> On Mon, Jun 02, 2008 at 02:45:10PM +0200, Andreas Gruenbacher wrote:
> > Without the vfsmount, when something is mounted in more than once place,
> > you cannot report which of the name aliases a process is accessing. This
> > is unacceptable; the logs would become unusable. With pathname-based, the
> > AppArmor and TOMOYO folks really mean pathname-based, not a hybrid
> > pathname / mount point model.
>
> audit_getname manages to do this.
You would assume, but no: audit_getname() grabs a reference to the pwd and the
absolute or relative pathname. The vfs resolves this to a dentry, but there
is no guarantee that the audit system will end up with the same pathname for
reporting: the namespace may have changed arbitrarily in the meantime.
(I find it rather interesting that this is consistent enough for audit; in my
opinion it isn't.)
On the other hand, AppArmor computes the path it uses for checking from the
dentry/vfsmount atomically with respect to namespace changes, and so the path
used for checking and reporting is always consistent (and it is guaranteed
that the object has been reachable via this path at the time the path has
been generated).
Andreas
Hi.
On Mon, Jun 02, 2008 at 12:55:33PM +0200, Miklos Szeredi ([email protected]) wrote:
> Oh, I've been told. But valid technical reason given? No.
This is a really interesting flame, can you proceed,
we will run for cola and peanuts :)
For the technical reason: in case of stackable/bind, which path should
be checked? Whatever answer is, there will always be another party,
which wants different behaviour.
--
Evgeniy Polyakov
2008/6/3 Evgeniy Polyakov <[email protected]>:
> On Mon, Jun 02, 2008 at 12:55:33PM +0200, Miklos Szeredi ([email protected]) wrote:
>> Oh, I've been told. But valid technical reason given? No.
>
> This is a really interesting flame, can you proceed,
> we will run for cola and peanuts :)
Let me quote a message by Chris Wright from LSM ml:
"You cannot discover the path used to access an inode without knowing
both the dentry and the vfsmount objects. "
Another one by Stephen Smalley:
"Pathname-based security considered harmful. You want to control access
to an object, not a name, and the name-to-object mapping is neither
one-to-one nor immutable."
Can you guess when they were posted?
The answer is December 2003. :)
Do we need more time? I don't think so.
I'm viewing Miklos' patches as *enhancements* not only for AppArmor (and
other pathname-based LSM modules). Everyone can make use of
information and lose nothing. Am I too simple minded?
> For the technical reason: in case of stackable/bind, which path should
> be checked? Whatever answer is, there will always be another party,
> which wants different behaviour.
--
Toshiharu Harada
[email protected]
On Tue, Jun 03, 2008 at 12:31:14AM +0900, Toshiharu Harada ([email protected]) wrote:
> > This is a really interesting flame, can you proceed,
> > we will run for cola and peanuts :)
>
> Let me quote a message by Chris Wright from LSM ml:
> "You cannot discover the path used to access an inode without knowing
> both the dentry and the vfsmount objects. "
Depending on what path you really want. If you want it related to bind
mount, you can (trivially). And even full path with vfsmount with
additional work.
Without any single additional patch on top of security system.
It maybe a bit slower, more complex, duplicate, whatever...
Active security was never a fast solution and was never a compromiss
between those who like it and who do not.
Technically you can be inside created limits and formally do not change
security model, but in practice implement you lovely path based security
checks.
> Another one by Stephen Smalley:
> "Pathname-based security considered harmful. You want to control access
> to an object, not a name, and the name-to-object mapping is neither
> one-to-one nor immutable."
For those who care exactly about path, they do not want to have security
checks for object, which was there. As addition, selinux
maintainer/architector opinion is a bit biassed :)
> Can you guess when they were posted?
> The answer is December 2003. :)
> Do we need more time? I don't think so.
Apparently we do :)
> I'm viewing Miklos' patches as *enhancements* not only for AppArmor (and
> other pathname-based LSM modules). Everyone can make use of
> information and lose nothing. Am I too simple minded?
What I wanted to say, is that people who do want to implement theirs
idea, will find a way to do it without breaking other approach.
With additional changes, with more complex approach, more code and
possibly some duplication/optimization/whatever.
So, if people continue to kick theirs head to the wall, they want
exactly that flame, that void talks and so on :)
--
Evgeniy Polyakov
2008/6/3 Evgeniy Polyakov <[email protected]>:
> On Tue, Jun 03, 2008 at 12:31:14AM +0900, Toshiharu Harada ([email protected]) wrote:
>> > This is a really interesting flame, can you proceed,
>> > we will run for cola and peanuts :)
>>
>> Let me quote a message by Chris Wright from LSM ml:
>> "You cannot discover the path used to access an inode without knowing
>> both the dentry and the vfsmount objects. "
>
> Depending on what path you really want. If you want it related to bind
> mount, you can (trivially). And even full path with vfsmount with
> additional work.
>
> Without any single additional patch on top of security system.
>
> It maybe a bit slower, more complex, duplicate, whatever...
> Active security was never a fast solution and was never a compromiss
> between those who like it and who do not.
>
> Technically you can be inside created limits and formally do not change
> security model, but in practice implement you lovely path based security
> checks.
>
>> Another one by Stephen Smalley:
>> "Pathname-based security considered harmful. You want to control access
>> to an object, not a name, and the name-to-object mapping is neither
>> one-to-one nor immutable."
>
> For those who care exactly about path, they do not want to have security
> checks for object, which was there. As addition, selinux
> maintainer/architector opinion is a bit biassed :)
This is a very important point.
The world of Linux consists of the two pieces, userland and kernel.
Objects have names and inodes. Information flow control need to be
handled using inodes (labels), but pathnames need to be
controlled because objects are represented by names in userland.
Both pieces work together. Vfsmount is a missing piece.
AppArmor and TOMOYO Linux are not claiming they are better MAC for Linux.
(that's how I understood Stephen's words. I am agreed)
So people don't have to eliminate pathname-based MACs.
>> Can you guess when they were posted?
>> The answer is December 2003. :)
>> Do we need more time? I don't think so.
>
> Apparently we do :)
Okay, I'll go and get my coke. ;)
>> I'm viewing Miklos' patches as *enhancements* not only for AppArmor (and
>> other pathname-based LSM modules). Everyone can make use of
>> information and lose nothing. Am I too simple minded?
>
> What I wanted to say, is that people who do want to implement theirs
> idea, will find a way to do it without breaking other approach.
> With additional changes, with more complex approach, more code and
> possibly some duplication/optimization/whatever.
100% agreed.
> So, if people continue to kick theirs head to the wall, they want
> exactly that flame, that void talks and so on :)
--
Toshiharu Harada
[email protected]
On Tue, Jun 03, 2008 at 01:29:33AM +0900, Toshiharu Harada ([email protected]) wrote:
> > For those who care exactly about path, they do not want to have security
> > checks for object, which was there. As addition, selinux
> > maintainer/architector opinion is a bit biassed :)
>
> This is a very important point.
>
> The world of Linux consists of the two pieces, userland and kernel.
> Objects have names and inodes. Information flow control need to be
> handled using inodes (labels), but pathnames need to be
> controlled because objects are represented by names in userland.
> Both pieces work together. Vfsmount is a missing piece.
>
> AppArmor and TOMOYO Linux are not claiming they are better MAC for Linux.
> (that's how I understood Stephen's words. I am agreed)
> So people don't have to eliminate pathname-based MACs.
They can, if really want, to get vfsmount.
A hint: there is security_sb_check_sb() and security_sb_post_addmount().
Store that vsmount in private cache, search the very root dentry for any inode
inside that cache of vfsmounts and get a pointer. Looks a bit ugly
though, and slower (really a bit), but it can solve a problem.
It is also possible to implement own path cache isntead of using dentry
cache, since apparently dentry is not needed neither to apparmor nor to
tomoyo, but path info (in own format). And that will be even better
solution, since it will be exactly what selinux does with its data.
Only to different objects. This will complicate move/rename and other
pathname manipulation. There are of course underwater rocks, but they
can be worked out with existing inode-biased approach.
--
Evgeniy Polyakov
Quoting Christoph Hellwig ([email protected]):
> On Mon, Jun 02, 2008 at 11:52:52AM +0200, Miklos Szeredi wrote:
> > These patches fix several issues raised at previous submissions:
> >
> > - passing NULL vfsmounts
> > - using nameidata
> > - using extra stack for vfsmount argument
> >
> > So, it seems to me that there's in fact no issues remaining and the
> > best excuse you can come up with is that it's a dumb idea. Well,
> > that's not a very imressive technical argument IMNSHO.
>
> Well, pathname based access control is a dumb idea, and we've been
> through this N times. You've also been told that vfs_ routines should
> remain without vfsmount, and no that's not a stack-related issue no idea
> where that part came from.
Sorry, noone else asked, so just out of curiosity - the *actual* reason
is api layering? Or am I missing another reason?
thanks,
-serge
2008/6/3 Evgeniy Polyakov <[email protected]>:
> On Tue, Jun 03, 2008 at 01:29:33AM +0900, Toshiharu Harada ([email protected]) wrote:
>> > For those who care exactly about path, they do not want to have security
>> > checks for object, which was there. As addition, selinux
>> > maintainer/architector opinion is a bit biassed :)
>>
>> This is a very important point.
>>
>> The world of Linux consists of the two pieces, userland and kernel.
>> Objects have names and inodes. Information flow control need to be
>> handled using inodes (labels), but pathnames need to be
>> controlled because objects are represented by names in userland.
>> Both pieces work together. Vfsmount is a missing piece.
>>
>> AppArmor and TOMOYO Linux are not claiming they are better MAC for Linux.
>> (that's how I understood Stephen's words. I am agreed)
>> So people don't have to eliminate pathname-based MACs.
>
> They can, if really want, to get vfsmount.
>
> A hint: there is security_sb_check_sb() and security_sb_post_addmount().
> Store that vsmount in private cache, search the very root dentry for any inode
> inside that cache of vfsmounts and get a pointer. Looks a bit ugly
> though, and slower (really a bit), but it can solve a problem.
> It is also possible to implement own path cache isntead of using dentry
> cache, since apparently dentry is not needed neither to apparmor nor to
> tomoyo, but path info (in own format). And that will be even better
> solution, since it will be exactly what selinux does with its data.
> Only to different objects. This will complicate move/rename and other
> pathname manipulation. There are of course underwater rocks, but they
> can be worked out with existing inode-biased approach.
>
> --
> Evgeniy Polyakov
Actually, another option has been suggested last month.
http://lkml.org/lkml/2008/4/9/93
Miklos' patches seem to me well suited after vfs cleanup jobs, but...
--
Toshiharu Harada
[email protected]
> Actually, another option has been suggested last month.
> http://lkml.org/lkml/2008/4/9/93
Yes, thanks for the link.
Here's the relevant quote from that mail from Stephen Smalley:
"2) Submit patches to add new security hooks to the callers where the
vfsmount is already available (some have suggested moving the
existing security_inode hooks to the callers, but that would cause
problems for SELinux as I've posted elsewhere, so adding new hooks
is preferable, and then SELinux can just default to the dummy
functions for those new hooks)."
True, this is an alternative, but from the VFS point of view it's
actually _worse_ than moving the hooks out, since we now have two sets
of security hooks littering the code for no good reason.
If Matthew Wilcox's idea can be made to work, that's obviously the
best, since it means that the VFS doesn't need to be touched at all.
Otherwise passing down vfsmounts is a superior solution to everything
else. It has *absolutely* *no* downsides. None, zero, zilch.
Well apart from the matter of VFS maintainers opinions. But damit,
this is an open source project, where decisions are made on technical
merit, and not on personal whims.
If the VFS maintainers don't like it, they better state their reasons
in clear and concise terms. An no, things like "someone might perhaps
maybe in the future need to call the vfs without a vfsmount" is
absolutely not a good reason. When we have such a caller, we'll fix
the code. It happens all the time. Prepering for everything that
might happen is called overdesign and it's one of the worst and
commonest mistakes in software engineering.
Miklos
Quoting Christoph wrote:
> Well, pathname based access control is a dumb idea, and we've been
> through this N times.
I have a question for you.
Matthew Wilcox wrote:
> Yes, if someone mounts /etc onto /etc2/ and has a rule to allow them to
> access /etc/shadow, they will then be able to access /etc2/shadow as
> well (which they weren't able to under previous apparmour). But I can't
> think of a way that permits Something Bad to happen (since the contents
> of the file could have been accessed through /etc/shadow *anyway*).
No. Something Bad happens even if you use object based access controls.
Andreas Gruenbacher wrote:
> One consequence of this is that pathname-based models must control who is
> allowed to create aliases where, of course.
The object based access controls *also* have to care about pathnames,
or Something Bad happens.
Have you ever thought that the pathname plays some part of security?
Please read part 3 and part 4 of http://lkml.org/lkml/2008/4/12/63 if
you have never thought that.
"Applications depend on pathnames, not on inode's number or labels.
Thinking little of pathnames leads to serious result."
Why do you think it is a bad thing to implement an access control that
restricts pathnames?