Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: Jeremy Maitin-Shepard <jbms@xxxxxxx>
- Date: Fri, 25 May 2007 14:10:41 -0400
Casey Schaufler <casey@xxxxxxxxxxxxxxxx> writes:
--- Jeremy Maitin-Shepard <jbms@xxxxxxx> wrote:
Casey Schaufler <casey@xxxxxxxxxxxxxxxx> writes:
On Fedora zcat, gzip and gunzip are all links to the same file.
I can imagine (although it is a bit of a stretch) allowing a set
of users access to gunzip but not gzip (or the other way around).
There are probably more sophisticated programs that have different
behavior based on the name they're invoked by that would provide
a more compelling arguement, assuming of course that you buy into
the behavior-based-on-name scheme. What I think I'm suggesting is
that AppArmor might be useful in addressing the fact that a file
with multiple hard links is necessarily constrained to have the
same access control on each of those names. That assumes one
believes that such behavior is flawwed, and I'm not going to try
to argue that. The question was about an example, and there is one.
This doesn't work. The behavior depends on argv[0], which is not
necessarily the same as the name of the file.
Sorry, but I don't understand your objection. If AppArmor is configured
to allow everyone access to /bin/gzip but only some people access to
/bin/gunzip and (important detail) the single binary uses argv[0]
as documented and (another important detail) there aren't other links
named gunzip to the binary (ok, that's lots of if's) you should be fine.
I suppose you could make a shell that lies to exec, but the AppArmor
code could certainly check for that in exec by enforcing the argv[0]
convention. It would be perfectly reasonable for a system that is so
dependent on pathnames to require that.
Well, my point was exactly that App Armor doesn't (as far as I know) do
anything to enforce the argv[0] convention, nor would it in general
prevent a confined program from making a symlink or hard link. Even
disregarding that, it seems very fragile in general to make an suid
program (there would be no point in confining the execution of a
non-suid program) perform essentially access control based on argv[0].
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: Casey Schaufler
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: Jeremy Maitin-Shepard
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- References:
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- From: Casey Schaufler
- Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- Prev by Date: Re: [patch] sched_clock(): cleanups, #2
- Next by Date: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- Previous by thread: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- Next by thread: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
- Index(es):
Relevant Pages
|
Loading
