From: Daniel J Walsh <dwalsh@redhat.com>
To: Sven Vermeulen <sven.vermeulen@siphos.be>
Cc: SELinux <selinux@tycho.nsa.gov>
Subject: Re: policy for PowerDNS
Date: Wed, 05 Dec 2012 06:51:54 -0500 [thread overview]
Message-ID: <50BF355A.3090708@redhat.com> (raw)
In-Reply-To: <CAPzO=NyBgG7q8yqzxzQGnePN6FyuxRi_5YEKLc+t4tuH3Kao3w@mail.gmail.com>
-----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.
next prev parent reply other threads:[~2012-12-05 11:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-03 14:22 policy for PowerDNS Sander Hoentjen
2012-12-03 15:08 ` grift
2012-12-04 11:37 ` Sander Hoentjen
2012-12-04 14:14 ` Daniel J Walsh
2012-12-04 21:11 ` Sven Vermeulen
2012-12-05 11:51 ` Daniel J Walsh [this message]
2012-12-05 13:10 ` Sander Hoentjen
2012-12-05 19:24 ` Sven Vermeulen
2012-12-24 12:48 ` Sander Hoentjen
[not found] ` <50DC666E.4040101@redhat.com>
2012-12-27 15:23 ` Sander Hoentjen
2012-12-27 17:21 ` Daniel J Walsh
2013-01-03 13:47 ` Sander Hoentjen
2013-01-03 13:52 ` Daniel J Walsh
2013-01-03 16:40 ` Daniel J Walsh
2013-01-04 14:11 ` Sander Hoentjen
2012-12-03 15:10 ` grift
2012-12-04 9:56 ` Sander Hoentjen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50BF355A.3090708@redhat.com \
--to=dwalsh@redhat.com \
--cc=selinux@tycho.nsa.gov \
--cc=sven.vermeulen@siphos.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.