Tinydns Policy Files

Tinydns Policy Files

[Matthew J. Fanto]

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

Here are updated policy files for tinydns. This is the first policy file
I've written, so I'd appreciate any feedback. This was written for
Debian stable.

-Matthew J. Fanto

[-- Attachment #2: tinydns.fc --]
[-- Type: text/plain, Size: 406 bytes --]

# tinydns
/etc/tinydns?			system_u:object_r:tinydns_conf_t
/etc/tinydns/root(/.*)?		system_u:object_r:tinydns_conf_t
/etc/tinydns/env(/.*)?		system_u:object_r:tinydns_conf_t
/etc/tinydns/root/data* --      system_u:object_r:tinydns_zone_t
/etc/tinydns/run*	--	system_u:object_r:tinydns_exec_t
/etc/tinydns/log/run*	--	system_u:object_r:tinydns_exec_t
/usr/bin/tinydns*	--	system_u:object_r:tinydns_exec_t


[-- Attachment #3: tinydns.te --]
[-- Type: text/plain, Size: 2207 bytes --]

#DESC TINYDNS - Policy file for the tinydns authoritative nameserver
#
# Author:  Matthew J. Fanto <mattjf@uncompiled.com>
# 
#   Based off Named policy file written by
# 	Yuichi Nakamura <ynakam@ori.hitachi-sk.co.jp>,
# 	Russell Coker <russell@coker.com.au>
#
# X-Debian-Packages: djbdns-installer djbdns

# we only define tinydns_port_t if we aren't
# using named or nsd, as it would conflict
ifdef(`named.te', `', `
ifdef(`nsd.te', `', `
type tinydns_port_t, port_type;
')dnl end if nsd.te
')dnl end if named.te

daemon_domain(tinydns)

# allow programs in the tinydns_t domain to execute tinydns_exec_t binaries
can_exec(tinydns_t, tinydns_exec_t)

# type for tinydns config files (/etc/tinydns(/.*)?) but does not
# include zone files
type tinydns_conf_t, file_type, sysadmfile;

# for primary zone files (/etc/selinux/root/data)
type tinydns_zone_t, file_type, sysadmfile;

# allow tinydns access to a few files it needs
allow tinydns_t etc_t:file { getattr read };
allow tinydns_t etc_runtime_t:{ file lnk_file } { getattr read };
allow tinydns_t resolv_conf_t:file { getattr read };
allow tinydns_t sbin_t:dir search;

# tinydns can use the network
can_network(tinydns_t)
allow tinydns_t tinydns_port_t:{ udp_socket } name_bind;
can_udp_send(domain, tinydns_t)
can_udp_send(tinydns_t, domain)
allow tinydns_t self:unix_dgram_socket create_socket_perms;

# read configuration files and zone files
r_dir_file(tinydns_t, tinydns_conf_t)
r_dir_file(tinydns_t, tinydns_zone_t)

# tinydns writes to a fifo and multilog reads it
# this is used for logging
ifdef(`daemontools.te', `
allow tinydns_t svc_start_t:fd { use };
allow tinydns_t svc_start_t:fifo_file { write };
')	

# allow tinydns to read /proc/meminfo
allow tinydns_t proc_t:file { getattr read };

# allow tinydns to search /etc/tinydns/log
allow tinydns_t svc_log_t:dir { getattr search };

# allow tinydns to search /bin
allow tinydns_t bin_t:dir { search };

# allow tinydns to gettar svc_run_exec_t files
ifdef(`daemontools.te', `
can_exec(tinydns_t, svc_run_exec_t)
domain_auto_trans(tinydns_t, svc_run_exec_t, svc_run_t)
')

# Set capabilites
allow tinydns_t self:capability { sys_tty_config net_bind_service sys_chroot setgid setuid };

Re: Tinydns Policy Files

[Russell Coker]

On Mon, 3 May 2004 03:17, "Matthew J. Fanto" <mattjf@uncompiled.com> wrote:
> Here are updated policy files for tinydns. This is the first policy file
> I've written, so I'd appreciate any feedback. This was written for
> Debian stable.

Is it possible to configure this and the other DJB tools in a sane manner?  
For starters entry point executables should not be under /etc.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Tinydns Policy Files

[Matthew J. Fanto]

On Sun, 2004-05-02 at 19:19, Russell Coker wrote:
> Is it possible to configure this and the other DJB tools in a sane manner?  
> For starters entry point executables should not be under /etc.

This is djb's recomended way of doing it. It's also the default for
Debians packages. It might require a decent amount of work to do it
differently. 

-Matthew J. Fanto


--
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: Tinydns Policy Files

[Milan P. Stanic]

On Sun, May 02, 2004 at 09:22:33PM -0400, Matthew J. Fanto wrote:
> On Sun, 2004-05-02 at 19:19, Russell Coker wrote:
> > Is it possible to configure this and the other DJB tools in a sane manner?  
> > For starters entry point executables should not be under /etc.

What do you mean by "entry point executables"?

> This is djb's recomended way of doing it. It's also the default for
> Debians packages. It might require a decent amount of work to do it
> differently. 

Binaries are in /package/admin/{package-name}. Only run scripts and
config files are under /etc

[ I may be wrong, but I'm using DJB tools a long ago under LIDS, and
  I always install them that way ]


--
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: Tinydns Policy Files

[Russell Coker]

On Mon, 3 May 2004 18:51, "Milan P. Stanic" <mps@rns-nis.co.yu> wrote:
> On Sun, May 02, 2004 at 09:22:33PM -0400, Matthew J. Fanto wrote:
> > On Sun, 2004-05-02 at 19:19, Russell Coker wrote:
> > > Is it possible to configure this and the other DJB tools in a sane
> > > manner? For starters entry point executables should not be under /etc.
>
> What do you mean by "entry point executables"?

something_exec_t, a type that's used as the second parameter in a 
domain_auto_trans() rule.

Having them for cron jobs under /etc/cron.something is bad enough.

> > This is djb's recomended way of doing it. It's also the default for
> > Debians packages. It might require a decent amount of work to do it
> > differently.
>
> Binaries are in /package/admin/{package-name}. Only run scripts and
> config files are under /etc

Breaking with all Unix conventions.  It's supposed to be /sbin and /usr/sbin 
for daemons.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Tinydns Policy Files

[Chris Babcock]

> On Mon, 3 May 2004 18:51, "Milan P. Stanic" <mps@rns-nis.co.yu> wrote:
>> On Sun, May 02, 2004 at 09:22:33PM -0400, Matthew J. Fanto wrote:
>> > On Sun, 2004-05-02 at 19:19, Russell Coker wrote:
>> > > Is it possible to configure this and the other DJB tools in a sane
>> > > manner? For starters entry point executables should not be under
>> /etc.
>>
>> What do you mean by "entry point executables"?
>
> something_exec_t, a type that's used as the second parameter in a
> domain_auto_trans() rule.
>
> Having them for cron jobs under /etc/cron.something is bad enough.
>
>> > This is djb's recomended way of doing it. It's also the default for
>> > Debians packages. It might require a decent amount of work to do it
>> > differently.
>>
>> Binaries are in /package/admin/{package-name}. Only run scripts and
>> config files are under /etc
>
> Breaking with all Unix conventions.  It's supposed to be /sbin and
> /usr/sbin
> for daemons.
>
The binaries for djb stuff installs somewhere under /usr/local by default
for everything except qmail and daemontools.

Dan recommends that daemontools be installed into "/package".  After some
dissection this appears to mostly be because the daemontools service
manager is launched from the inittab, and some pain can be caused by not
having the binaries for it on the root filesystem.  I have at times
installed daemontools in other places.  Other locations work fine, however
filesystem repair tends to be annoying. <I can provide details if anybody
cares...>

The stuff that ends up in etc is generally control files w/named pipes,
config files w/empty chroot directories, and default minimal logs (limited
to 1MB or so by default, if I remember right).

Strictly speaking, the service directories can be placed anywhere.  Dan's
examples all put them in /etc, but there is no technical reason they need
to be in /etc.  All that is really required is that a sym link exists
between a  "/service/<service-instance-name>" and the real service
directory that was created, and whatever users the processes run under
generally need to be able to read some subsection of the real service
directory.

Anybody have any ideas about where these service directories should go in
a se system?  My instinct tells me that they should probably go somewhere
in /var on an se system, but it is a tough call since many sysadmins have
their own ideas about where service directories should go.

For sanity in policy distribution, it is probably going to be necessary to
"strongly recommend" service directories be in a specific location.

> --
> http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
> http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> http://www.coker.com.au/~russell/  My home page
>
> --
> 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: Tinydns Policy Files

[Milan P. Stanic]

On Mon, May 03, 2004 at 05:33:32AM -0700, Chris Babcock wrote:
> The binaries for djb stuff installs somewhere under /usr/local by default
> for everything except qmail and daemontools.

Right. I made mistake in previous mail.
 
> Dan recommends that daemontools be installed into "/package".  After some
> dissection this appears to mostly be because the daemontools service
> manager is launched from the inittab, and some pain can be caused by not
> having the binaries for it on the root filesystem.  I have at times
> installed daemontools in other places.  Other locations work fine, however
> filesystem repair tends to be annoying. <I can provide details if anybody
> cares...>

I'd like hear why repair "tends to be annoying"?
 
> The stuff that ends up in etc is generally control files w/named pipes,
> config files w/empty chroot directories, and default minimal logs (limited
> to 1MB or so by default, if I remember right).

Logs can be easily put under /var/log . I did that always.
 
[...]
> Anybody have any ideas about where these service directories should go in
> a se system?  My instinct tells me that they should probably go somewhere
> in /var on an se system, but it is a tough call since many sysadmins have
> their own ideas about where service directories should go.

I have them under /var/svc (I'm lazy man, hate to type too much :-) )
on some of my servers, but I'm moving them back to /etc . Log dirs are
under /var/log and supervise dirs are symlinks to
/var/run/{service-name}

Under runit package (daemontools replacement) for debian symlinks are
under /var/service (I'll have to type more :-) ) but the run files are
under /etc/runit

For systems without security policies (SELinux, GRSec, LIDS) this mess
isn't problem, but for system with SELinux it should be standardized.
I thought about that but I don't have sane idea how.

> For sanity in policy distribution, it is probably going to be necessary to
> "strongly recommend" service directories be in a specific location.

I agree.

--
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: Tinydns Policy Files

[Valdis.Kletnieks]

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

On Mon, 03 May 2004 16:30:23 +0200, "Milan P. Stanic" <mps@rns-nis.co.yu>  said:

> > Dan recommends that daemontools be installed into "/package".  After some
> > dissection this appears to mostly be because the daemontools service
> > manager is launched from the inittab, and some pain can be caused by not
> > having the binaries for it on the root filesystem.  I have at times
> > installed daemontools in other places.  Other locations work fine, however
> > filesystem repair tends to be annoying. <I can provide details if anybody
> > cares...>
> 
> I'd like hear why repair "tends to be annoying"?

I think he means all the many variants on "the tool you need to get /usr restored
was installed in /usr/sbin rather than /sbin"... :)

RedHat/Fedora had a similar whoops in the LVM package - it got linked against
libreadline.so, which was in /usr/lib.  Loads of fun if your /usr is on an LVM partition
and you need to run /sbin/lvm first to get it mounted....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Tinydns Policy Files

[Chris Babcock]

> On Mon, May 03, 2004 at 05:33:32AM -0700, Chris Babcock wrote:
>> Dan recommends that daemontools be installed into "/package".  After
>> some
>> dissection this appears to mostly be because the daemontools service
>> manager is launched from the inittab, and some pain can be caused by not
>> having the binaries for it on the root filesystem.  I have at times
>> installed daemontools in other places.  Other locations work fine,
>> however
>> filesystem repair tends to be annoying. <I can provide details if
>> anybody
>> cares...>
>
> I'd like hear why repair "tends to be annoying"?
>
Daemontools launches a set of processes from inittab something like the
following ps listing...
11203 ?        Ss     0:00 /bin/sh /command/svscanboot
11205 ?        S      0:06  \_ svscan /service
12445 ?        S      0:00  |   \_ supervise httpd
12446 ?        S      0:00  |   \_ supervise log
12449 ?        S      0:00  |   |   \_ multilog t ./main -* +* * status:
12447 ?        S      0:00  |   \_ supervise ftpd
12448 ?        S      0:00  |   \_ supervise log
12450 ?        S      0:00  |   |   \_ multilog t ./main -* +* * status:
15148 ?        S      0:00  |   \_ supervise dnscache
15149 ?        S      0:00  |   \_ supervise log
15151 ?        S      0:00  |   |   \_ multilog t /var/multilog/dnscache
15150 ?        S      0:00  |   \_ supervise tinydns
15152 ?        S      0:00  |   \_ supervise log
15153 ?        S      0:00  |       \_ multilog t /var/multilog/tinydns
11206 ?        S      0:00  \_ readproctitle service errors:.............

The way the system works is that svscanboot monitors readproctitle and
svscan.  Init launches and monitors svscanboot. Svscan monitors the
/service directory on the machine for linked directories for service
control.  When svscan finds a directory that needs a service controller,
it launches 2 supervise process.  Once supervise process controlls the
actual service process, another controls the logging subsystem for the
process.

In practice this monitoring tree provides a convenient (again, can detail
if anybody cares, but it is off topic for this list) ,if odd, way of
managing services and their logging.  However, unexpected death of the
bottom level svscan(boot) processes often causes dependent services to
exit as well.  If the supervise processes die, the services typically die
as well.  If svscanboot fails (or is killed), it will be restarted.

Under normal conditions I have _never_ had a svscan(boot) or supervise
process fail.  However, in order to to fsck /usr or /var, all of these
processes will have to be killed if the supervise binary is on the damaged
filesystem.  Unfortunately, there is pretty much no way to _keep_ them
dead, without editing inittab or shutting down to single user mode.  If
inittab is edited and the svscanboot process is removed, the entire
service tree dies.  At times this process death can be undesirable,
because process that are completely unrelated to the damage may have to be
stopped unnecessarily.  If the daemontools binaries are on the rootfs, the
only time a service stop is necessary is when the rootfs is damaged, or
when an individual service's resources are impacted.

Additionally, I dislike having direct dependencies in inittab on non
rootfs binaries.  Some part of me feels like I am inviting disaster.  This
reason may just be a reaction to pain from the Solaris /lib and /bin
symlink to /usr crap.  The following line from a debian inittab references
/sbin not /usr/sbin for a reason...

6:23:respawn:/sbin/getty 38400 tty6

-Chris


--
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: Tinydns Policy Files

[Russell Coker]

On Mon, 3 May 2004 22:33, "Chris Babcock" <cbabcock@luthresearch.com> wrote:
> > Breaking with all Unix conventions.  It's supposed to be /sbin and
> > /usr/sbin
> > for daemons.
>
> The binaries for djb stuff installs somewhere under /usr/local by default
> for everything except qmail and daemontools.

For any distribution with a packaging system (any RPM or dpkg based 
distribution) such things should not be installed in /usr/local.

> Dan recommends that daemontools be installed into "/package".  After some
> dissection this appears to mostly be because the daemontools service
> manager is launched from the inittab, and some pain can be caused by not

Launching from inittab means that the binaries should go in /sbin, /bin if 
they are used in some other way than as init scripts, and that any shared 
objects that they need should go in /lib.  Everyone else's software has been 
working well like this for decades.

> The stuff that ends up in etc is generally control files w/named pipes,

Named pipes in /etc, Solaris used to do that, it's really annoying.  Some 
early Linux distributions copied that mistake, but it's been corrected now.

> config files w/empty chroot directories, and default minimal logs (limited
> to 1MB or so by default, if I remember right).

Logs belong in /var/log.

> Anybody have any ideas about where these service directories should go in
> a se system?  My instinct tells me that they should probably go somewhere
> in /var on an se system, but it is a tough call since many sysadmins have
> their own ideas about where service directories should go.

The FHS should contain all the information you need.  It's not easy to read 
though so copying the practises of distributions such as Debian and Fedora is 
a much easier way of getting the same result.

> For sanity in policy distribution, it is probably going to be necessary to
> "strongly recommend" service directories be in a specific location.

Yes.  For the Qmail policy I put in both good file locations (as once used by 
Debian packages) and DJB's locations.  But it seems that those other programs 
are even messier, so I'm not sure it's a good idea to put the non-FHS 
locations in too.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Tinydns Policy Files

[Chris Babcock]

> On Mon, 3 May 2004 22:33, "Chris Babcock" <cbabcock@luthresearch.com>
> wrote:
>> > Breaking with all Unix conventions.  It's supposed to be /sbin and
>> > /usr/sbin
>> > for daemons.
>>
>> The binaries for djb stuff installs somewhere under /usr/local by
>> default
>> for everything except qmail and daemontools.
>
> For any distribution with a packaging system (any RPM or dpkg based
> distribution) such things should not be installed in /usr/local.
>
Last I checked, Dan still didn't permit distribution of binary packages
that  were modified in any way from the default as distributed in source. 
This includes changing default paths, etc.

This has pretty much been a roadblock, preventing non-source based
distributions from integrating any of the djb tools, and it has meant that
working with the djb tools always means working with source in some form.

It would be nice to have some documented guidelines and recommendations
for how to make the djb stuff work with an se system, but how necessary is
it to try to enforce distribution standards on a set of tools that can't
be integrated into a non-source distribution anyway?

I suspect that anybody using the djb tools who can't adapt a "default" djb
tools policy for their setup of the djb stuff on their system is probably
dead meat anyway.  Because even if the policy doesn't kill you, the sharp
edges on the djb tools load and install will.

Likewise any source based distro vendor is going to relocate the built
package components to where ever they want it anyway, and modify their se
policy to fit how they have broken down the package.

>> Dan recommends that daemontools be installed into "/package".  After
>> some
>> dissection this appears to mostly be because the daemontools service
>> manager is launched from the inittab, and some pain can be caused by not
>
> Launching from inittab means that the binaries should go in /sbin, /bin if
> they are used in some other way than as init scripts, and that any shared
> objects that they need should go in /lib.  Everyone else's software has
> been
> working well like this for decades.
>
I have put daemontools in dozens of different places over the years.  I
would have no trouble putting it in /sbin.  It can be done.  I typically
don't because I don't like to mix my source built tools with vendor
supplied binaries.

Same comment as above on standardization.

>> The stuff that ends up in etc is generally control files w/named pipes,
>
> Named pipes in /etc, Solaris used to do that, it's really annoying.  Some
> early Linux distributions copied that mistake, but it's been corrected
> now.
>
>> config files w/empty chroot directories, and default minimal logs
>> (limited
>> to 1MB or so by default, if I remember right).
>
> Logs belong in /var/log.
>
In general, yes.

>> Anybody have any ideas about where these service directories should go
>> in
>> a se system?  My instinct tells me that they should probably go
>> somewhere
>> in /var on an se system, but it is a tough call since many sysadmins
>> have
>> their own ideas about where service directories should go.
>
> The FHS should contain all the information you need.  It's not easy to
> read
> though so copying the practises of distributions such as Debian and Fedora
> is
> a much easier way of getting the same result.
>
>> For sanity in policy distribution, it is probably going to be necessary
>> to
>> "strongly recommend" service directories be in a specific location.
>
> Yes.  For the Qmail policy I put in both good file locations (as once used
> by
> Debian packages) and DJB's locations.  But it seems that those other
> programs
> are even messier, so I'm not sure it's a good idea to put the non-FHS
> locations in too.
>
For djbdns one way to make this work is to make a replacement version of
the dnscache-conf, tinydns-conf, and axfrdns-conf tools that also builds a
policy with the appropriate locations as specified when the user runs the
*-conf tool, possibly relocating some files to more se friendly locations.

> --
> http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
> http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
> http://www.coker.com.au/~russell/  My home page
>
> --
> 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: Tinydns Policy Files

[Milan P. Stanic]

On Mon, May 03, 2004 at 08:42:48PM +1000, Russell Coker wrote:
> On Mon, 3 May 2004 18:51, "Milan P. Stanic" <mps@rns-nis.co.yu> wrote:
> > What do you mean by "entry point executables"?
> 
> something_exec_t, a type that's used as the second parameter in a 
> domain_auto_trans() rule.

Thanks for explanation.
 
> > Binaries are in /package/admin/{package-name}. Only run scripts and
> > config files are under /etc
> 
> Breaking with all Unix conventions.  It's supposed to be /sbin and /usr/sbin 
> for daemons.

Actually, debian packages for djbdns and ucspi-tcp puts binaries under
/usr/bin (not /usr/sbin ???). Only daemontools binaries are under
/package/admin

Regarding conventions: for sake of progress we have to break them
from time to time :-)


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