On 12/27/2012 04:17 PM, Daniel J Walsh wrote:
> On 12/24/2012 07:48 AM, Sander Hoentjen wrote:
>> 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.
>
>
>
> What is the path to the bin_t? I am not opposed to allow it to execute random
> bin_t, but if this is a constant path, then labeling it would be more secure.
> named_helper_exec_t or something.
>
Well, there is not a fixed path at this moment. The point of the
pipe-backend is that you can easily write your own script/binary. Then
in the config you tell pdns where it is located. So then in the
documentation for the pipe-backend we could write that in the case of
selinux you either need top put it in the right path, or apply the
correct label yourself.
--
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.
