[Sorry for the delay in responding to this.] On Tue, Jul 22, 2014 at 12:16:53PM -0700, John Johansen wrote: > Recently a bug was opened due to a misunderstanding of how apparmor's > script handling and permissions work. > > https://bugs.launchpad.net/apparmor/+bug/1346553 > > Basically the profile that a script runs under does not need r or x > permissions on the interpreter (generally). The question was raised > if this is the behavior that is desired, or whether a script profile > should require access permissions to the interpreters binary. > > AppArmor used to do this years ago, and it would be fairly trivial to > add it back in (kernel change only). And it could be conditional on > ABI versioning to maintain compatability. > > So that only leaves the question of whether we should keep the > current behavior or require explicit permissions for the interpreter > binary.
Truthfully, this was a behavioral change I had not noticed, nor did I expect. It seems to me that some form of permission on the interpreter for a confined script is important; being able to adjust the interpreter allowed based on modifying the script seems... dubious. There are a fair number of assumptions in policy that an interpreter will be required; for example, abstractions/base contains many variations of ld.so with "mrix" permissions, yet that no longer seems necessary for binfmt_elf binaries (I realize there's a difference int he kernel's handling of scripts via binfmt_misc and how elf binaries are handled with binfmt_elf, but they are analogous). All that said, it strikes me as a low priority issue, although I do have the nagging feeling there's a threat here with not requiring a permission that I can't quite articulate. -- Steve Beattie <[email protected]> http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
