On 12/05/2012 08:24 PM, Sven Vermeulen wrote:
> 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.
>
Trying to move the policy for pdns forward, do I understand correctly
that the following additions to the policy would be ok:
======pdns.fc======
/usr/sbin/pdns_server --
gen_context(system_u:object_r:named_exec_t,s0)
/etc/pdns/pdns\.conf --
gen_context(system_u:object_r:named_conf_t,s0)
/var/run/pdns\.controlsocket -s
gen_context(system_u:object_r:named_var_run_t,s0)
/var/run/pdns\.pid --
gen_context(system_u:object_r:named_var_run_t,s0)
===================
======pdns.te======
policy_module(pdns,0.0.1)
require{
type named_t;
}
#only needed if using the guardian
allow named_t self:capability { kill };
#gmysql backend:
mysql_read_config(named_t)
files_read_usr_files(named_t)
mysql_stream_connect(named_t)
#postgres backend:
postgresql_stream_connect(named_t)
===================
But the following addition to the .te is under discussion:
#pipe backend:
corecmd_exec_bin(named_t)
If i am correct up till this point, I would be okay with either having
corecmd_exec_bin in a boolean, or use a new type for this and add
documentation to pdns showing what type you need to make your pipe backend.
What do you guys think?
--
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.
