-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDcg4MACgkQrlYvE4MpobPoygCgq4h2mjdgi7ZVTXXet3s2L9Pl
GG8AoL3EqVKr54shB3nNLSlMb8SiA2HD
=nR2Q
-----END PGP SIGNATURE-----
--
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.
