I'm upgrading my DNS system to DNSSEC, and now I have public and private key files in /var/named. They of course got the type named_zone_t which is the default in that directory.
For the public keys, that is appropriate. The DNS server needs to read them, and they do contain zone data.
But it should not be able to read the private keys, and it can not because of MAC. It seemed prudent to me to also give them another type, just in case.
But what type would be appropriate? Just something generic like etc_t? Or does it exist some more specific type that would be more appropriate. I wasn't planning to add any extra policy modules or types just for this, only to add a fcontext pattern for these files.
Does anybody have any good suggestions?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Göran Uddeborg wrote:
I'm upgrading my DNS system to DNSSEC, and now I have public and private key files in /var/named. They of course got the type named_zone_t which is the default in that directory.
For the public keys, that is appropriate. The DNS server needs to read them, and they do contain zone data.
But it should not be able to read the private keys, and it can not because of MAC. It seemed prudent to me to also give them another type, just in case.
But what type would be appropriate? Just something generic like etc_t? Or does it exist some more specific type that would be more appropriate. I wasn't planning to add any extra policy modules or types just for this, only to add a fcontext pattern for these files.
Does anybody have any good suggestions?
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
grep dnssec /etc/selinux/targeted/contexts/files/file_contexts /etc/rndc.key -- system_u:object_r:dnssec_t:s0 /var/named/chroot/etc/rndc.key -- system_u:object_r:dnssec_t:s0
On Tue, 2009-02-17 at 15:00 -0500, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Göran Uddeborg wrote:
I'm upgrading my DNS system to DNSSEC, and now I have public and private key files in /var/named. They of course got the type named_zone_t which is the default in that directory.
For the public keys, that is appropriate. The DNS server needs to read them, and they do contain zone data.
But it should not be able to read the private keys, and it can not because of MAC. It seemed prudent to me to also give them another type, just in case.
But what type would be appropriate? Just something generic like etc_t? Or does it exist some more specific type that would be more appropriate. I wasn't planning to add any extra policy modules or types just for this, only to add a fcontext pattern for these files.
Does anybody have any good suggestions?
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
grep dnssec /etc/selinux/targeted/contexts/files/file_contexts /etc/rndc.key -- system_u:object_r:dnssec_t:s0 /var/named/chroot/etc/rndc.key -- system_u:object_r:dnssec_t:s0
That's readable by named_t.
Why are you putting the private key in /var/named at all? Why is it even on the public server?
Daniel J Walsh writes:
grep dnssec /etc/selinux/targeted/contexts/files/file_contexts /etc/rndc.key -- system_u:object_r:dnssec_t:s0 /var/named/chroot/etc/rndc.key -- system_u:object_r:dnssec_t:s0
I thought that file was just for connection between the named server and rndc clients. I didn't think it had anything to do with DNSSEC at all. Am I wrong?
I'm talking about keys for signing a zone, in files having names like Kuddeborg.se.+005+16744.key and Kuddeborg.se.+005+16744.private respectively.
Stephen Smalley writes:
Why are you putting the private key in /var/named at all? Why is it even on the public server?
Well, I haven't been able to run dnssec-signzone without having both the private and public keys in the same directory. But maybe I just haven't figured these things out? These DNSSEC tools are new to me.
On Tue, 2009-02-17 at 22:06 +0100, Göran Uddeborg wrote:
Daniel J Walsh writes:
grep dnssec /etc/selinux/targeted/contexts/files/file_contexts /etc/rndc.key -- system_u:object_r:dnssec_t:s0 /var/named/chroot/etc/rndc.key -- system_u:object_r:dnssec_t:s0
I thought that file was just for connection between the named server and rndc clients. I didn't think it had anything to do with DNSSEC at all. Am I wrong?
It seems to be a bit of a misnomer; I assume that someone named it dnssec_t because the TSIG key is generated via dnssec-keygen as well.
I'm talking about keys for signing a zone, in files having names like Kuddeborg.se.+005+16744.key and Kuddeborg.se.+005+16744.private respectively.
Stephen Smalley writes:
Why are you putting the private key in /var/named at all? Why is it even on the public server?
Well, I haven't been able to run dnssec-signzone without having both the private and public keys in the same directory. But maybe I just haven't figured these things out? These DNSSEC tools are new to me.
Do you have to support dynamic updates or not?
On Tue, 2009-02-17 at 20:37 +0100, Göran Uddeborg wrote:
I'm upgrading my DNS system to DNSSEC, and now I have public and private key files in /var/named. They of course got the type named_zone_t which is the default in that directory.
For the public keys, that is appropriate. The DNS server needs to read them, and they do contain zone data.
But it should not be able to read the private keys, and it can not because of MAC. It seemed prudent to me to also give them another type, just in case.
But what type would be appropriate? Just something generic like etc_t? Or does it exist some more specific type that would be more appropriate. I wasn't planning to add any extra policy modules or types just for this, only to add a fcontext pattern for these files.
Does anybody have any good suggestions?
I don't think there is an appropriate type defined in the existing policy for a DNSSEC private key. The best option would be to add a local policy module defining a distinct type exclusively for this purpose e.g.:
$ cat mydnssec.te policy_module(mydnssec, 1.0) type mydnssec_private_t; files_type(mydnssec_private_t)
$ cat mydnssec.fc /var/named/K.*.private -- gen_context(system_u:object_r:mydnssec_private_t,s0)
$ make -f /usr/share/selinux/devel/Makefile mydnssec.pp $ sudo semodule -i mydnssec.pp $ sudo restorecon -Rv /var/named
Then only domains with unconfined file access should be allowed to access the file (which would include your login account unless you are mapping your account to a confined user role).
selinux@lists.fedoraproject.org