On 12/27/2012 06:21 PM, Daniel J Walsh wrote:
> On 12/27/2012 10:23 AM, Sander Hoentjen wrote:
>> 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.
>
> Well it is not quite that easy, since the back end would be running as a
> random label, we would have to write policy about more then just executing the
> script but also all of the access required for the dns server to talk to this
> back end. Stuff like connecting to a labeled unix fifo file or sock file,
> connecting to a processes running what ever label the process is running with.
>
Well, in the simple case this is not needed, the example script[1] is
just a simple perl script, that needs no extra access. But I guess you
mean that if this script does things not allowed for named_t then it
will fail. I guess you are right, but I do not know what would be a good
way to fix this. It doesn't matter in this case if it is bin_t or some
other type, right?
[1]
http://wiki.powerdns.com/trac/browser/trunk/pdns/modules/pipebackend/backend.pl
--
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.
