--- 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. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
