Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Jeremy Maitin-Shepard <[EMAIL PROTECTED]> writes: > [snip] > 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]. Note that by "confining the execution of a non-suid program", I mean defining an App Armor profile that prevents the execution of a particular non-suid program, unless of course the program file itself contains secret information, which is irrelevant to this discussion. -- Jeremy Maitin-Shepard - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
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. -- Jeremy Maitin-Shepard - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
