On Sat, Jan 14, 2012 at 12:22 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > We've had security bugs that were *due* to dropped capabilities - > people dropped one capability but not another, and fooled code into > doing things they weren't expecting it to do. So quite frankly, I > believe that from a security standpoint it's a hell of a lot safer to > just keep the rules really simple. > Which is the point of this patch. If suid/sgid/file caps/LSM transitions are disabled, you can't exploit thinks like sendmail because they don't have any special privileges to exploit. > > Does "dropping" mean allowing setuid(geteuid()) for example? That *is* > dropping the uid in a _POSIX_SAVED_IDS environment. And I'm saying > that no, we should not even allow that. It's simply all too "subtle". > > (I don't think Andrew's patch actually touched any of those paths, but > I didn't check) Correct. I did not touch any of these paths. I think that's the right choice for at least three reasons: 1. If there's an exploit that does PR_SET_NO_NEW_CAPS, then setuid/capset/whatever, then runs something and exploits it, it is likely to work just as will if setuid/capset is called before PR_SET_NO_NEW_CAPS. 2. Even if I made that change, it wouldn't help. You can always simulate dropping capabilities with LD_PRELOAD or something like seccomp mode 2. The secure exec stuff that happens when you execve something with the setuid bit set won't prevent it because the setuid bit is *disabled* in this mode. (Again, there is no exploit here -- there are no new privileges to steal.) 3. Simplicity. It would be easy to miss something subtle. There's the dumpable bit and however it interacts with ptrace (especially on Ubuntu, which seems to have a patched kernel with different rules), there's capset, there's file capabilities (which can, I think, drop capabilities as well as adding them), there's cap_bset, securebits, etc. Leaving them all alone means I don't need to worry about bitrot or about missing one. I'm tempted to submit a followup patch to allow unprivileged users to use some of the sys_unshare modes if no_new_privs is set so we can have an example use case. CLONE_NEWIPC, CLONE_SYSVSEM, and CLONE_NEWUTS would be a decent start, I think, and the patch would be trivial. --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
