Andy Lutomirski wrote: > > So I bet the google chrome people are not at all interested in > > "running random binaries", and might want execve() very much for > > "running some specific binaries that we ship with or install from the > > browser". > > I want to be able to run "magic_seccomp_sandbox gv somefile.ps". And > I want that to still work even if my distro gets fancy and uses > selinux policy to prevent gv from accessing the network (which would > not be an unreasonable thing to do). The chromium project already has > a little seccomp wrapper that can (sort of) do this. Chrome also comes with NaCL. They *are* "running random binaries", but they use code analysis to check the code first. Maybe because seccomp wasn't good enough ;-) > > So I really think that the *only* valid model is the "fail the execve > > on any changes", not the "mnt-nosuid" approach of trying to run things > > with the wrong permissions and get perhaps odd results. And I think it > > works even - and perhaps *especially* - in models like selinux or > > apparmor that do have a lot of "implicit MAC knowledge" on specific > > binaries. > > 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? -- Jamie -- 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
