-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/03/2013 08:47 AM, Sander Hoentjen wrote:
> 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
>
>
Well we could setup a label for these scripts so that users could label them
with an unconfined type, Or allow admins to write policy specific for the script.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDljTgACgkQrlYvE4MpobPtCwCgqH99UiRGnFR8cpGNDY6lY/6L
DucAn2GZY86xenf1lgWMBbsTqTg1eaGg
=Ba+N
-----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.
