On Sat, Jan 14, 2012 at 7:17 AM, Eric Paris <eparis@xxxxxxxxxx> wrote: > -----Original Message----- > From: Jamie Lokier [jamie@xxxxxxxxxxxxx] > Andy Lutomirski wrote: > >> Is the current exec_no_trans check enough for you? With my patch, >> selinux can already block the execve if it wants. (The policy is the >> same as it would be if a program explicitly asked to run the new >> executable with an unchanged security context.) I'd be happy to fail >> the exec in AppArmor, and then maybe AppArmor will change its mind >> if/when users get annoyed :) > > Does SELinux block if userspace does exec entirely in userspace using > mmap() and not execve()? If not, why is execve() allowed to be different? > > Yes, we do (or can, and usually do in policy) > By blocking open, read, mmap, or mprotect? And, more to the point, why? I've always found it weird/annoying that selinux blocks things that can neither be used to gain privilege nor to DoS the system. Certainly a fully confined selinux program can emulate the execution of anything it can read -- it just might be slow. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
