Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Casey Schaufler <[email protected]> writes:

> --- Jeremy Maitin-Shepard <[email protected]> wrote:
>> Casey Schaufler <[email protected]> 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 [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]
  Powered by Linux