On Wed, Dec 05, 2012 at 06:51:54AM -0500, Daniel J Walsh wrote: > > If named by default doesn't require this access, doesn't it make sense to > > keep it restricted? Remote code execution vulnerabilities might be > > mitigated if the policy prohibits execution of common binaries > > > > Reading /usr however seems less problematic (I'm even surprised it doesn't > > require this already). > > Perhaps but if you have enough control over a process to execute random > binaries, one would guess you have enough control to call other syscalls > implemented in those binaries. I can follow your reasoning, but I disagree. Remote command execution can be done either in a very simple way (for instance, user input that is not correctly sanitized and that is directly used for spawning specific commands) or through memory manipulation. Let's say it is memory manipulation, then there are imho two ways this can lead to a remote command execution: data memory or execution memory. Either the memory is data (non-executable) and is used by the application for its flows, logic and what else. In this case, you won't have the ability to invoke syscalls yourself (through the exploit) but you can manipulate the application, which underlyingly might use the data to spawn commands. Or the memory is code (executable). In this case, if you can manipulate this, then you indeed have control over the application completely and can invoke system calls yourself. The majority of Remote Code Execution vulnerabilities, imho, plays in the data memory, not in the executable memory. For one, because executable memory shouldn't be writeable in the first place (you can use PaX or other constraints for that). It is also harder to manipulate this code to the extend that you can do useful things with it. But if we're talking about data memory manipulation/corruption, then the syscalls don't play a role, and SELinux can reduce the impact of such vulnerabilities if you can downplay what the domain is allowed to do. Such as executing generic binaries. Of course, an even better way to handle this is to chroot the named daemon itself so that there are no binaries to execute beyond those that are already needed. I do believe that chrooting named is still a very useful approach even if you use SELinux [1], but there are people that think differently. Wkr, Sven Vermeulen [1] http://blog.siphos.be/2012/04/why-both-chroot-and-selinux/ -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
