policy for PowerDNS

policy for PowerDNS

[Sander Hoentjen]

Hi all,

I had created a policy for PowerDNS (pdns package in Fedora), but after 
e-mailing with dwalsh he told me it might be better to just adapt the 
named policy a bit. Here is what I have so far:
======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;
}

#gmysql backend:
bool pdns_can_connect_db true;
tunable_policy(`pdns_backend_mysql', `
     mysql_read_config(named_t)
     #socket
     mysql_stream_connect(named_t)
')
===================
With this added pdns works with both the bind-backend and the 
mysql-backend (pdns-backend-mysql in Fedora). I do still get some 
denials, first 2 with both backends:
type=AVC msg=audit(12/03/2012 14:30:26.767:597) : avc:  denied  { fsetid 
} for  pid=23063 comm=pdns_server capability=fsetid 
scontext=system_u:system_r:named_t:s0 
tcontext=system_u:system_r:named_t:s0 tclass=capability

type=AVC msg=audit(12/03/2012 14:30:26.735:595) : avc:  denied  { kill } 
for  pid=20597 comm=pdns_server capability=kill 
scontext=system_u:system_r:named_t:s0 
tcontext=system_u:system_r:named_t:s0 tclass=capability

For this I can add:
allow named_t self:capability { fsetid kill };
but I am not sure if that is okay, can anyone please advise?

Last one I get with the mysql backend:
type=AVC msg=audit(12/03/2012 13:37:52.315:545) : avc:  denied  { 
getattr } for  pid=20772 comm=pdns_server 
path=/usr/share/mysql/charsets/Index.xml dev="dm-0" ino=8936 
scontext=system_u:system_r:named_t:s0 
tcontext=system_u:object_r:usr_t:s0 tclass=file
To allow this I will have to allow read access from named_t to usr_t, 
would that be okay?

Kind regards,

Sander

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[grift]

On Mon, 2012-12-03 at 15:22 +0100, Sander Hoentjen wrote:
> Hi all,
> 
> I had created a policy for PowerDNS (pdns package in Fedora), but after 
> e-mailing with dwalsh he told me it might be better to just adapt the 
> named policy a bit. Here is what I have so far:
> ======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;
> }
> 
> #gmysql backend:
> bool pdns_can_connect_db true;
> tunable_policy(`pdns_backend_mysql', `
>      mysql_read_config(named_t)
>      #socket
>      mysql_stream_connect(named_t)
> ')
> ===================
> With this added pdns works with both the bind-backend and the 
> mysql-backend (pdns-backend-mysql in Fedora). I do still get some 
> denials, first 2 with both backends:
> type=AVC msg=audit(12/03/2012 14:30:26.767:597) : avc:  denied  { fsetid 
> } for  pid=23063 comm=pdns_server capability=fsetid 
> scontext=system_u:system_r:named_t:s0 
> tcontext=system_u:system_r:named_t:s0 tclass=capability
> 
> type=AVC msg=audit(12/03/2012 14:30:26.735:595) : avc:  denied  { kill } 
> for  pid=20597 comm=pdns_server capability=kill 
> scontext=system_u:system_r:named_t:s0 
> tcontext=system_u:system_r:named_t:s0 tclass=capability
> 
> For this I can add:
> allow named_t self:capability { fsetid kill };
> but I am not sure if that is okay, can anyone please advise?
> 
> Last one I get with the mysql backend:
> type=AVC msg=audit(12/03/2012 13:37:52.315:545) : avc:  denied  { 
> getattr } for  pid=20772 comm=pdns_server 
> path=/usr/share/mysql/charsets/Index.xml dev="dm-0" ino=8936 
> scontext=system_u:system_r:named_t:s0 
> tcontext=system_u:object_r:usr_t:s0 tclass=file
> To allow this I will have to allow read access from named_t to usr_t, 
> would that be okay?

Yes, the capabilities are a pity, but it is give and take, so all
considering this looks ok to me

> Kind regards,
> 
> Sander
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[grift]

On Mon, 2012-12-03 at 15:22 +0100, Sander Hoentjen wrote:
> Hi all,
> 
> I had created a policy for PowerDNS (pdns package in Fedora), but after 
> e-mailing with dwalsh he told me it might be better to just adapt the 
> named policy a bit. Here is what I have so far:
> ======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)

escape the periods here though to minimize chances of error

> ===================
> ======pdns.te======
> policy_module(pdns,0.0.1)
> 
> require{
>      type named_t;
> }
> 
> #gmysql backend:
> bool pdns_can_connect_db true;
> tunable_policy(`pdns_backend_mysql', `
>      mysql_read_config(named_t)
>      #socket
>      mysql_stream_connect(named_t)
> ')
> ===================
> With this added pdns works with both the bind-backend and the 
> mysql-backend (pdns-backend-mysql in Fedora). I do still get some 
> denials, first 2 with both backends:
> type=AVC msg=audit(12/03/2012 14:30:26.767:597) : avc:  denied  { fsetid 
> } for  pid=23063 comm=pdns_server capability=fsetid 
> scontext=system_u:system_r:named_t:s0 
> tcontext=system_u:system_r:named_t:s0 tclass=capability
> 
> type=AVC msg=audit(12/03/2012 14:30:26.735:595) : avc:  denied  { kill } 
> for  pid=20597 comm=pdns_server capability=kill 
> scontext=system_u:system_r:named_t:s0 
> tcontext=system_u:system_r:named_t:s0 tclass=capability
> 
> For this I can add:
> allow named_t self:capability { fsetid kill };
> but I am not sure if that is okay, can anyone please advise?
> 
> Last one I get with the mysql backend:
> type=AVC msg=audit(12/03/2012 13:37:52.315:545) : avc:  denied  { 
> getattr } for  pid=20772 comm=pdns_server 
> path=/usr/share/mysql/charsets/Index.xml dev="dm-0" ino=8936 
> scontext=system_u:system_r:named_t:s0 
> tcontext=system_u:object_r:usr_t:s0 tclass=file
> To allow this I will have to allow read access from named_t to usr_t, 
> would that be okay?
> 
> Kind regards,
> 
> Sander
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Sander Hoentjen]

On 12/03/2012 04:10 PM, grift wrote:
> On Mon, 2012-12-03 at 15:22 +0100, Sander Hoentjen wrote:
>> Hi all,
>>
>> I had created a policy for PowerDNS (pdns package in Fedora), but after
>> e-mailing with dwalsh he told me it might be better to just adapt the
>> named policy a bit. Here is what I have so far:
>> ======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)
>
> escape the periods here though to minimize chances of error
>
Thanks, I fixed that now.
-- 
Sander

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Sander Hoentjen]

On 12/03/2012 04:08 PM, grift wrote:
> On Mon, 2012-12-03 at 15:22 +0100, Sander Hoentjen wrote:
>> Hi all,
>>
>> I had created a policy for PowerDNS (pdns package in Fedora), but after
>> e-mailing with dwalsh he told me it might be better to just adapt the
>> named policy a bit. Here is what I have so far:
>> ======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;
>> }
>>
>> #gmysql backend:
>> bool pdns_can_connect_db true;
>> tunable_policy(`pdns_backend_mysql', `
>>       mysql_read_config(named_t)
>>       #socket
>>       mysql_stream_connect(named_t)
>> ')
>> ===================
>> With this added pdns works with both the bind-backend and the
>> mysql-backend (pdns-backend-mysql in Fedora). I do still get some
>> denials, first 2 with both backends:
>> type=AVC msg=audit(12/03/2012 14:30:26.767:597) : avc:  denied  { fsetid
>> } for  pid=23063 comm=pdns_server capability=fsetid
>> scontext=system_u:system_r:named_t:s0
>> tcontext=system_u:system_r:named_t:s0 tclass=capability
>>
>> type=AVC msg=audit(12/03/2012 14:30:26.735:595) : avc:  denied  { kill }
>> for  pid=20597 comm=pdns_server capability=kill
>> scontext=system_u:system_r:named_t:s0
>> tcontext=system_u:system_r:named_t:s0 tclass=capability
>>
>> For this I can add:
>> allow named_t self:capability { fsetid kill };
>> but I am not sure if that is okay, can anyone please advise?
>>
>> Last one I get with the mysql backend:
>> type=AVC msg=audit(12/03/2012 13:37:52.315:545) : avc:  denied  {
>> getattr } for  pid=20772 comm=pdns_server
>> path=/usr/share/mysql/charsets/Index.xml dev="dm-0" ino=8936
>> scontext=system_u:system_r:named_t:s0
>> tcontext=system_u:object_r:usr_t:s0 tclass=file
>> To allow this I will have to allow read access from named_t to usr_t,
>> would that be okay?
>
> Yes, the capabilities are a pity, but it is give and take, so all
> considering this looks ok to me
>
Ok, thank you.
I was a bit surprised that named_t already had access to a mysql 
database by the way.

PowerDNS has some more backends, next I have a question about is the 
pipe backend:
This backend executes a file specified in the config, that will echo the 
response to STDOUT. Should there be a seperate domain for that pipe 
command, or is it okay to allow exec to bin_t? For now I chose the 
latter, and my .te looks like this:
======pdns.te======
policy_module(pdns,0.0.1)

require{
	type named_t;
}

allow named_t self:capability { kill fsetid };

#gmysql backend:
bool pdns_backend_mysql true;
tunable_policy(`pdns_backend_mysql', `
	mysql_read_config(named_t)
	files_read_usr_files(named_t)
	#socket
	mysql_stream_connect(named_t)
')

bool pdns_backend_pipe false;
tunable_policy(`pdns_backend_pipe', `
	corecmd_exec_bin(named_t)
	files_read_usr_files(named_t)
')
===================
This, together with the .fc results in a working powerdns for me. If 
there are no further objections, what would be the next step to get this 
accepted in the (Fedora?) policy?
-- 
Sander

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/04/2012 06:37 AM, Sander Hoentjen wrote:
> On 12/03/2012 04:08 PM, grift wrote:
>> On Mon, 2012-12-03 at 15:22 +0100, Sander Hoentjen wrote:
>>> Hi all,
>>> 
>>> I had created a policy for PowerDNS (pdns package in Fedora), but
>>> after e-mailing with dwalsh he told me it might be better to just adapt
>>> the named policy a bit. Here is what I have so far: 
>>> ======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; }
>>> 
>>> #gmysql backend: bool pdns_can_connect_db true; 
>>> tunable_policy(`pdns_backend_mysql', ` mysql_read_config(named_t) 
>>> #socket mysql_stream_connect(named_t) ') =================== With this
>>> added pdns works with both the bind-backend and the mysql-backend
>>> (pdns-backend-mysql in Fedora). I do still get some denials, first 2
>>> with both backends: type=AVC msg=audit(12/03/2012 14:30:26.767:597) :
>>> avc:  denied  { fsetid } for  pid=23063 comm=pdns_server
>>> capability=fsetid scontext=system_u:system_r:named_t:s0 
>>> tcontext=system_u:system_r:named_t:s0 tclass=capability
>>> 
>>> type=AVC msg=audit(12/03/2012 14:30:26.735:595) : avc:  denied  { kill
>>> } for  pid=20597 comm=pdns_server capability=kill 
>>> scontext=system_u:system_r:named_t:s0 
>>> tcontext=system_u:system_r:named_t:s0 tclass=capability
>>> 
>>> For this I can add: allow named_t self:capability { fsetid kill }; but
>>> I am not sure if that is okay, can anyone please advise?
>>> 
>>> Last one I get with the mysql backend: type=AVC msg=audit(12/03/2012
>>> 13:37:52.315:545) : avc:  denied  { getattr } for  pid=20772
>>> comm=pdns_server path=/usr/share/mysql/charsets/Index.xml dev="dm-0"
>>> ino=8936 scontext=system_u:system_r:named_t:s0 
>>> tcontext=system_u:object_r:usr_t:s0 tclass=file To allow this I will
>>> have to allow read access from named_t to usr_t, would that be okay?
>> 
>> Yes, the capabilities are a pity, but it is give and take, so all 
>> considering this looks ok to me
>> 
> Ok, thank you. I was a bit surprised that named_t already had access to a
> mysql database by the way.
> 
> PowerDNS has some more backends, next I have a question about is the pipe
> backend: This backend executes a file specified in the config, that will
> echo the response to STDOUT. Should there be a seperate domain for that
> pipe command, or is it okay to allow exec to bin_t? For now I chose the
> latter, and my .te looks like this: ======pdns.te====== 
> policy_module(pdns,0.0.1)
> 
> require{ type named_t; }
> 
> allow named_t self:capability { kill fsetid };
> 
> #gmysql backend: bool pdns_backend_mysql true; 
> tunable_policy(`pdns_backend_mysql', ` mysql_read_config(named_t) 
> files_read_usr_files(named_t) #socket mysql_stream_connect(named_t) ')
> 
> bool pdns_backend_pipe false; tunable_policy(`pdns_backend_pipe', ` 
> corecmd_exec_bin(named_t) files_read_usr_files(named_t) ') 
> =================== This, together with the .fc results in a working
> powerdns for me. If there are no further objections, what would be the next
> step to get this accepted in the (Fedora?) policy?

I don't see why rading usr_files or executing a bin_t file requires a boolean,
I would just add the access.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlC+BSkACgkQrlYvE4MpobNg9gCgijAiMt49CU7e3bzjnUlRlTc8
b6gAmgJjuwAK5DA41BJYHTT8TL75A8FG
=ModI
-----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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 4789 bytes --]

On Dec 4, 2012 3:16 PM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:

> I don't see why rading usr_files or executing a bin_t file requires a
boolean,
> I would just add the access.

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).

Wkr,
  Sven


On Tue, Dec 4, 2012 at 3:14 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/04/2012 06:37 AM, Sander Hoentjen wrote:
> > On 12/03/2012 04:08 PM, grift wrote:
> >> On Mon, 2012-12-03 at 15:22 +0100, Sander Hoentjen wrote:
> >>> Hi all,
> >>>
> >>> I had created a policy for PowerDNS (pdns package in Fedora), but
> >>> after e-mailing with dwalsh he told me it might be better to just adapt
> >>> the named policy a bit. Here is what I have so far:
> >>> ======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; }
> >>>
> >>> #gmysql backend: bool pdns_can_connect_db true;
> >>> tunable_policy(`pdns_backend_mysql', ` mysql_read_config(named_t)
> >>> #socket mysql_stream_connect(named_t) ') =================== With this
> >>> added pdns works with both the bind-backend and the mysql-backend
> >>> (pdns-backend-mysql in Fedora). I do still get some denials, first 2
> >>> with both backends: type=AVC msg=audit(12/03/2012 14:30:26.767:597) :
> >>> avc:  denied  { fsetid } for  pid=23063 comm=pdns_server
> >>> capability=fsetid scontext=system_u:system_r:named_t:s0
> >>> tcontext=system_u:system_r:named_t:s0 tclass=capability
> >>>
> >>> type=AVC msg=audit(12/03/2012 14:30:26.735:595) : avc:  denied  { kill
> >>> } for  pid=20597 comm=pdns_server capability=kill
> >>> scontext=system_u:system_r:named_t:s0
> >>> tcontext=system_u:system_r:named_t:s0 tclass=capability
> >>>
> >>> For this I can add: allow named_t self:capability { fsetid kill }; but
> >>> I am not sure if that is okay, can anyone please advise?
> >>>
> >>> Last one I get with the mysql backend: type=AVC msg=audit(12/03/2012
> >>> 13:37:52.315:545) : avc:  denied  { getattr } for  pid=20772
> >>> comm=pdns_server path=/usr/share/mysql/charsets/Index.xml dev="dm-0"
> >>> ino=8936 scontext=system_u:system_r:named_t:s0
> >>> tcontext=system_u:object_r:usr_t:s0 tclass=file To allow this I will
> >>> have to allow read access from named_t to usr_t, would that be okay?
> >>
> >> Yes, the capabilities are a pity, but it is give and take, so all
> >> considering this looks ok to me
> >>
> > Ok, thank you. I was a bit surprised that named_t already had access to a
> > mysql database by the way.
> >
> > PowerDNS has some more backends, next I have a question about is the pipe
> > backend: This backend executes a file specified in the config, that will
> > echo the response to STDOUT. Should there be a seperate domain for that
> > pipe command, or is it okay to allow exec to bin_t? For now I chose the
> > latter, and my .te looks like this: ======pdns.te======
> > policy_module(pdns,0.0.1)
> >
> > require{ type named_t; }
> >
> > allow named_t self:capability { kill fsetid };
> >
> > #gmysql backend: bool pdns_backend_mysql true;
> > tunable_policy(`pdns_backend_mysql', ` mysql_read_config(named_t)
> > files_read_usr_files(named_t) #socket mysql_stream_connect(named_t) ')
> >
> > bool pdns_backend_pipe false; tunable_policy(`pdns_backend_pipe', `
> > corecmd_exec_bin(named_t) files_read_usr_files(named_t) ')
> > =================== This, together with the .fc results in a working
> > powerdns for me. If there are no further objections, what would be the
> next
> > step to get this accepted in the (Fedora?) policy?
>
> I don't see why rading usr_files or executing a bin_t file requires a
> boolean,
> I would just add the access.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlC+BSkACgkQrlYvE4MpobNg9gCgijAiMt49CU7e3bzjnUlRlTc8
> b6gAmgJjuwAK5DA41BJYHTT8TL75A8FG
> =ModI
> -----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@tycho.nsa.govwith
> the words "unsubscribe selinux" without quotes as the message.
>

[-- Attachment #2: Type: text/html, Size: 6194 bytes --]

Re: policy for PowerDNS

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/04/2012 04:11 PM, Sven Vermeulen wrote:
> On Dec 4, 2012 3:16 PM, "Daniel J Walsh" <dwalsh@redhat.com 
> <mailto:dwalsh@redhat.com>> wrote:
> 
>> I don't see why rading usr_files or executing a bin_t file requires a
>> boolean, I would just add the access.
> 
> 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).
> 
> Wkr, Sven
> 
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.
> 
> 
> On Tue, Dec 4, 2012 at 3:14 PM, Daniel J Walsh <dwalsh@redhat.com 
> <mailto:dwalsh@redhat.com>> wrote:
> 
> On 12/04/2012 06:37 AM, Sander Hoentjen wrote:
>> On 12/03/2012 04:08 PM, grift wrote:
>>> On Mon, 2012-12-03 at 15:22 +0100, Sander Hoentjen wrote:
>>>> Hi all,
>>>> 
>>>> I had created a policy for PowerDNS (pdns package in Fedora), but 
>>>> after e-mailing with dwalsh he told me it might be better to just
>>>> adapt the named policy a bit. Here is what I have so far: 
>>>> ======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; }
>>>> 
>>>> #gmysql backend: bool pdns_can_connect_db true; 
>>>> tunable_policy(`pdns_backend_mysql', ` mysql_read_config(named_t) 
>>>> #socket mysql_stream_connect(named_t) ') =================== With
>>>> this added pdns works with both the bind-backend and the
>>>> mysql-backend (pdns-backend-mysql in Fedora). I do still get some
>>>> denials, first 2 with both backends: type=AVC msg=audit(12/03/2012
>>>> 14:30:26.767:597) : avc:  denied  { fsetid } for  pid=23063
>>>> comm=pdns_server capability=fsetid
>>>> scontext=system_u:system_r:named_t:s0 
>>>> tcontext=system_u:system_r:named_t:s0 tclass=capability
>>>> 
>>>> type=AVC msg=audit(12/03/2012 14:30:26.735:595) : avc:  denied  {
>>>> kill } for  pid=20597 comm=pdns_server capability=kill 
>>>> scontext=system_u:system_r:named_t:s0 
>>>> tcontext=system_u:system_r:named_t:s0 tclass=capability
>>>> 
>>>> For this I can add: allow named_t self:capability { fsetid kill };
>>>> but I am not sure if that is okay, can anyone please advise?
>>>> 
>>>> Last one I get with the mysql backend: type=AVC msg=audit(12/03/2012 
>>>> 13:37:52.315:545) : avc:  denied  { getattr } for  pid=20772 
>>>> comm=pdns_server path=/usr/share/mysql/charsets/Index.xml dev="dm-0" 
>>>> ino=8936 scontext=system_u:system_r:named_t:s0 
>>>> tcontext=system_u:object_r:usr_t:s0 tclass=file To allow this I will 
>>>> have to allow read access from named_t to usr_t, would that be okay?
>>> 
>>> Yes, the capabilities are a pity, but it is give and take, so all 
>>> considering this looks ok to me
>>> 
>> Ok, thank you. I was a bit surprised that named_t already had access to
>> a mysql database by the way.
> 
>> PowerDNS has some more backends, next I have a question about is the
>> pipe backend: This backend executes a file specified in the config, that
>> will echo the response to STDOUT. Should there be a seperate domain for
>> that pipe command, or is it okay to allow exec to bin_t? For now I chose
>> the latter, and my .te looks like this: ======pdns.te====== 
>> policy_module(pdns,0.0.1)
> 
>> require{ type named_t; }
> 
>> allow named_t self:capability { kill fsetid };
> 
>> #gmysql backend: bool pdns_backend_mysql true; 
>> tunable_policy(`pdns_backend_mysql', ` mysql_read_config(named_t) 
>> files_read_usr_files(named_t) #socket mysql_stream_connect(named_t) ')
> 
>> bool pdns_backend_pipe false; tunable_policy(`pdns_backend_pipe', ` 
>> corecmd_exec_bin(named_t) files_read_usr_files(named_t) ') 
>> =================== This, together with the .fc results in a working 
>> powerdns for me. If there are no further objections, what would be the
>> next step to get this accepted in the (Fedora?) policy?
> 
> I don't see why rading usr_files or executing a bin_t file requires a
> boolean, I would just add the access.
> 
> -- This message was distributed to subscribers of the selinux mailing
> list. If you no longer wish to subscribe, send mail to
> majordomo@tycho.nsa.gov <mailto:majordomo@tycho.nsa.gov> with the words
> "unsubscribe selinux" without quotes as the message.
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlC/NVoACgkQrlYvE4MpobOSOQCeJOSmqUTpowH4qpy0BvMBz4wJ
dskAoKso5THVN3TnUpOmxkj57gSC025Z
=yjhN
-----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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Sander Hoentjen]

On 12/05/2012 12:51 PM, Daniel J Walsh wrote:
> On 12/04/2012 04:11 PM, Sven Vermeulen wrote:
>> On Dec 4, 2012 3:16 PM, "Daniel J Walsh" <dwalsh@redhat.com 
>> <mailto:dwalsh@redhat.com>> wrote:
> 
>>> I don't see why rading usr_files or executing a bin_t file requires a
>>> boolean, I would just add the access.
> 
>> 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).
> 
>> Wkr, Sven
> 
> 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.
> 
> 
>> On Tue, Dec 4, 2012 at 3:14 PM, Daniel J Walsh <dwalsh@redhat.com 
>> <mailto:dwalsh@redhat.com>> wrote:
> 
>> On 12/04/2012 06:37 AM, Sander Hoentjen wrote:
>>> On 12/03/2012 04:08 PM, grift wrote:
>>>> On Mon, 2012-12-03 at 15:22 +0100, Sander Hoentjen wrote:
>>>>> Hi all,
>>>>>
>>>>> I had created a policy for PowerDNS (pdns package in Fedora), but 
>>>>> after e-mailing with dwalsh he told me it might be better to just
>>>>> adapt the named policy a bit. Here is what I have so far: 
>>>>> ======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; }
>>>>>
>>>>> #gmysql backend: bool pdns_can_connect_db true; 
>>>>> tunable_policy(`pdns_backend_mysql', ` mysql_read_config(named_t) 
>>>>> #socket mysql_stream_connect(named_t) ') =================== With
>>>>> this added pdns works with both the bind-backend and the
>>>>> mysql-backend (pdns-backend-mysql in Fedora). I do still get some
>>>>> denials, first 2 with both backends: type=AVC msg=audit(12/03/2012
>>>>> 14:30:26.767:597) : avc:  denied  { fsetid } for  pid=23063
>>>>> comm=pdns_server capability=fsetid
>>>>> scontext=system_u:system_r:named_t:s0 
>>>>> tcontext=system_u:system_r:named_t:s0 tclass=capability
>>>>>
>>>>> type=AVC msg=audit(12/03/2012 14:30:26.735:595) : avc:  denied  {
>>>>> kill } for  pid=20597 comm=pdns_server capability=kill 
>>>>> scontext=system_u:system_r:named_t:s0 
>>>>> tcontext=system_u:system_r:named_t:s0 tclass=capability
>>>>>
>>>>> For this I can add: allow named_t self:capability { fsetid kill };
>>>>> but I am not sure if that is okay, can anyone please advise?
>>>>>
>>>>> Last one I get with the mysql backend: type=AVC msg=audit(12/03/2012 
>>>>> 13:37:52.315:545) : avc:  denied  { getattr } for  pid=20772 
>>>>> comm=pdns_server path=/usr/share/mysql/charsets/Index.xml dev="dm-0" 
>>>>> ino=8936 scontext=system_u:system_r:named_t:s0 
>>>>> tcontext=system_u:object_r:usr_t:s0 tclass=file To allow this I will 
>>>>> have to allow read access from named_t to usr_t, would that be okay?
>>>>
>>>> Yes, the capabilities are a pity, but it is give and take, so all 
>>>> considering this looks ok to me
>>>>
>>> Ok, thank you. I was a bit surprised that named_t already had access to
>>> a mysql database by the way.
> 
>>> PowerDNS has some more backends, next I have a question about is the
>>> pipe backend: This backend executes a file specified in the config, that
>>> will echo the response to STDOUT. Should there be a seperate domain for
>>> that pipe command, or is it okay to allow exec to bin_t? For now I chose
>>> the latter, and my .te looks like this: ======pdns.te====== 
>>> policy_module(pdns,0.0.1)
> 
>>> require{ type named_t; }
> 
>>> allow named_t self:capability { kill fsetid };
> 
>>> #gmysql backend: bool pdns_backend_mysql true; 
>>> tunable_policy(`pdns_backend_mysql', ` mysql_read_config(named_t) 
>>> files_read_usr_files(named_t) #socket mysql_stream_connect(named_t) ')
> 
>>> bool pdns_backend_pipe false; tunable_policy(`pdns_backend_pipe', ` 
>>> corecmd_exec_bin(named_t) files_read_usr_files(named_t) ') 
>>> =================== This, together with the .fc results in a working 
>>> powerdns for me. If there are no further objections, what would be the
>>> next step to get this accepted in the (Fedora?) policy?
> 
>> I don't see why rading usr_files or executing a bin_t file requires a
>> boolean, I would just add the access.

Based on the feedback my .te now looks like the following. You might
notice the kill and fsetid are gone. fsetid is gone because a patch[1]
for that is commited in pdns. Kill is gone because that is needed by the
guardian process, but we don't need that if we let systemd do this job
instead[2].
Now I guess the last boolean might not make a lot of sense either: We
can already connect to mysql over localhost, just not over the socket.
======pdns.te======
policy_module(pdns,0.0.1)

require{
        type named_t;
}

files_read_usr_files(named_t)
#needed for pdns pipe backend
corecmd_exec_bin(named_t)

#gmysql backend:
bool pdns_backend_mysql true;
tunable_policy(`pdns_backend_mysql', `
        mysql_read_config(named_t)
        #socket
        mysql_stream_connect(named_t)
')


[1]
<http://wiki.powerdns.com/trac/changeset?new=2965%40trunk%2Fpdns&old=2964%40trunk%2Fpdns>
[2] <https://bugzilla.redhat.com/show_bug.cgi?id=883852>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Sven Vermeulen]

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.

Wkr,
	Sven Vermeulen

[1] http://blog.siphos.be/2012/04/why-both-chroot-and-selinux/



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Sander Hoentjen]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Sander Hoentjen]

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@tycho.nsa.gov 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Daniel J Walsh]

-----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@tycho.nsa.gov 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Sander Hoentjen]

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@tycho.nsa.gov 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Daniel J Walsh]

-----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@tycho.nsa.gov 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Daniel J Walsh]

-----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@tycho.nsa.gov 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes
> as the message.
> 

Yes the question is do you expect admin to modify this script to do nutty
things or do you envision this script to only be used as is.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDltI8ACgkQrlYvE4MpobPKrwCcCZX3H1XHf4DmR2z+7LRlquGn
MZEAn1QAoGnQ6Bn1bT73wkOYObs8x0+e
=FOeI
-----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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: policy for PowerDNS

[Sander Hoentjen]

On 01/03/2013 05:40 PM, Daniel J Walsh wrote:
> 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@tycho.nsa.gov 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@tycho.nsa.gov with the words "unsubscribe selinux" without quotes
>> as the message.
> 
> 
> Yes the question is do you expect admin to modify this script to do nutty
> things or do you envision this script to only be used as is.
> 
Well, the script will not be used as is, but running the pipe-backend is
also not a main use-case of powerdns. Requiring pipe-backend users to
write their own policy when they want selinux protection would imho not
be a very bad option, since you can never know in advance how it will be
used.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.