On Fri, 13 Mar 2015, Andrew G. Morgan wrote: > > prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_SYS_ADMIN); > > system("/bin/bash"); > > Let's call the above two lines [a] and [b]. With this patch, you are > encouraging folk to write programs that contain a line like [a] > already. So, yes, I am saying that you are creating an exploitable > path in these programs that says if someone can inject > system("/bin/bash") into these programs they can get a new (because of > this patch) privilege escalation. Well this is what one naively expects capabilities to give you. An ability to avoid full superuser binaries by segmenting off capabilities. Often there is really no other choice. If you do not provide this mode then the system will be even less secure since people run stuff as root. This looks to many like the design of capabilties is inherent flawed since it does not give you what you need. You experience a go around that leads nowhere and just wastes your time. > In the prevailing model, this kind of privilege escalation (resulting > from naive inheritance) is designed out. I recognize that you want to > add it back in, but I am concerned that you are not allowing for the > possibility that some folk might still want to still be able to > prevent it. The functionalty here depends on CAP_SETPCAP. That was intended as some point to be off by default? You can have distros/kernels with that being off. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html