please offer your good advices / new policies: exim, dovecot, maradns, (aptitude)

please offer your good advices / new policies: exim, dovecot, maradns, (aptitude)

[Peter Gervai]

Hello,

I subscribed the list as I became confident that my contributions aren't
worthless after my very complex patch got into newrule.pl. :-)

Apart from kidding... I have had small and large problems with selinux, and
most of them was resolved by my humble self, or with the help of
#selinux@irc.debian.org, but I'm not confident that my policies are really
as secure as I would like to have them to be.

The server is a school server with some hundred young users, which was once
compromised, due to the clueless morons walking with root pw to be able to
create users and due to other morons being friends of the before mentioned
ones installing attacking software of questionnable source (not that the
source would change the roots of the problems) containing RST.B and other
linux viruses.

Now enough was enough, selinux goes on the system. 

Mailserver, dns, webserver, and some usual goodies run on it. Mailserver is
exim, dns was chosen maradns (it handles both auth and recur queries, free,
and the author isn't a moron :)), imap/pop is dovecot (pretty nice piece of
sw), apache is apache. Debian sid/unstable is the base with the valuable
help of Russel's packages.

My policies are on http://narya.grin.hu/selinux/policy/
There is a diff to help to show my actions, and the policies are there as
well if someone needs them.

I'd be happy if you would read the README and do what it says, which is
basically a beg for peer review of the beforementioned policies of mine and
sharing good advices.

				*

Other question: what is the advised way to have the server an admin
(staff_t?) who is able to create/delete users? Probably emitting user_u
users are okay in the beginning, because I believe everything more would
require policy reloading. (I'm checking this after this email anyway, but
maybe you're faster.)

This probably need changing to uid=0, and I see that there is no sudo.te in
the default... but I don't think sharing the root pw is better than su. Is
it safe to allow sudo setuid:capability? Does anyone already have a sudo.te?

				*

There was a question a month ago about dhcpc_t (and sshd_t and newrole_t in
cases) emitting this:

avc:  denied  { recvfrom } for  pid=1059 exe=/usr/sbin/exim saddr=10.1.1.16
 source=17664 daddr=10.1.1.1 dest=60 netif=eth0
 scontext=system_u:system_r:dhcpc_t tcontext=root:sysadm_r:sysadm_t
 tclass=packet_socket

(One line for every packet ever arriving on the network!)

I don't see the reason for this (I have wild guesses), and I don't see the
solution. And I don't get why nobody had this problem before. Shall I
dontaudit these (modifying dhcpc, newrole, sshd, ...)? Is there a better
solution?


Thanks for the reading,
Peter


--
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: please offer your good advices / new policies: exim, dovecot, maradns, (aptitude)

[Andreas Schuldei]

* Peter Gervai (grin@tolna.net) [030423 20:56]:
> (One line for every packet ever arriving on the network!)
> 
> I don't see the reason for this (I have wild guesses), and I don't see the
> solution. And I don't get why nobody had this problem before. Shall I
> dontaudit these (modifying dhcpc, newrole, sshd, ...)? Is there a better
> solution?

yes, that is what i did, too. (i think i asked the same question
here, too, and never got an answer.)

i have here collected over time:
dontaudit dhcpd_t sshd_t:packet_socket { recvfrom };
dontaudit dhcpd_t courier_tcpd_t:packet_socket { recvfrom };
dontaudit dhcpd_t netmsg_eth1_t:packet_socket { recvfrom };
dontaudit dhcpd_t icmp_socket_t:rawip_socket { recvfrom };
dontaudit dhcpd_t ping_t:rawip_socket { recvfrom };
dontaudit dhcpd_t named_t:packet_socket { recvfrom };
dontaudit dhcpd_t netmsg_eth0_t:packet_socket { recvfrom };
dontaudit dhcpd_t apt_t:packet_socket { recvfrom };
dontaudit dhcpd_t inetd_t:packet_socket { recvfrom };
dontaudit dhcpd_t postfix_master_t:packet_socket { recvfrom };
dontaudit dhcpd_t tcp_socket_t:packet_socket { recvfrom };
dontaudit dhcpd_t dhcpd_t:packet_socket { recvfrom };
dontaudit dhcpd_t icmp_socket_t:packet_socket { recvfrom };
dontaudit dhcpd_t sysadm_ssh_t:packet_socket { recvfrom };

basicly, these are all the services i run on that box.

--
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: please offer your good advices / new policies: exim, dovecot, maradns, (aptitude)

[Russell Coker]

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

On Thu, 24 Apr 2003 02:06, Peter Gervai wrote:
> My policies are on http://narya.grin.hu/selinux/policy/
> There is a diff to help to show my actions, and the policies are there as
> well if someone needs them.

In future please provide .tar.gz archives of policy as that makes it easier to 
download and reduces the risk of errors in transmission.  Some web browsers 
do silly things like converting from Unix to DOS text files, a .tar.gz file 
will generally escape unscathed.

# links to exim
#  leave them alone - putting them into exim_exec_t causes
#  programs to fail read on lnk_files.
You can put a "--" after the file name to specify that only file types (not 
links) are matched.

It would be good if we could have the main exim program labeled as 
sendmail_exec_t so it fits in better with mta.te (it's a pity that exim 
doesn't provide separate programs for the tasks of mail queuing and of the 
full mail server functionality).  mta.te is necessary for all mail servers.  
It's the base policy for running "sendmail -t" for sending mail from a 
program.  All mail servers that accept mail from local processes should use 
mta.te.

One thing I recommend for all daemons is to use the daemon_base_domain() or 
daemon_domain() macro as appropriate.  This gets all the base access a daemon 
needs and reduces the effort for someone who reads the policy, they can just 
see the daemon_domain() macro (which corresponds to over a dozen lines of 
policy that you wrote), know what it does, and keep reading.

The drawback for using daemon_domain in this situation is that it wants the 
executable type to be based on the name of the daemon domain.  So sendmail_t 
is required to match sendmail_exec_t (not what you desire).

To solve this we could change mta.te and mta_macros.te to use some ifdef's to 
use exim_exec_t in the case of exim and sendmail_exec_t for other mail 
servers.

I have attached a modified exim.te which contains some of the changes I 
suggest.  Also note that I removed every_domain() because it's bad.

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

[-- Attachment #2: exim.te --]
[-- Type: text/plain, Size: 2916 bytes --]

#DESC Exim - Mail server
#
# Authors:  Peter Gervai <grin@grin.hu>
# Original by: Stephen Smalley <sds@epoch.ncsc.mil> and Timothy Fraser  
#

#################################
#
# Rules for the exim_t domain.
#
# exim_t is the domain for the exim 
# daemon started by the init rc scripts.
#
# depends on mta.te
#
daemon_domain(exim, `, mta_delivery_agent')

tmp_domain(exim)
log_domain(exim)

# --<g>
type exim_spool_t, file_type, sysadmfile;
type etc_exim_t, file_type, sysadmfile;
# not strictly required
#file_type_auto_trans(exim_t, etc_t, etc_exim_t)

# Use capabilities
allow exim_t exim_t:capability { setuid setgid net_bind_service sys_nice chown };

# Use the network.
can_network(exim_t)
allow exim_t resolv_conf_t:file r_file_perms;

# Bind to the SMTP port.
allow exim_t smtp_port_t:tcp_socket name_bind;

# Write to /etc/aliases and /etc/mail.
#allow exim_t etc_aliases_t:file { setattr rw_file_perms };
#allow exim_t etc_mail_t:dir rw_dir_perms;
#allow exim_t etc_mail_t:file create_file_perms;

# Write to /var/spool/mail and /var/spool/mqueue.
allow exim_t mail_spool_t:dir rw_dir_perms;
allow exim_t mail_spool_t:file create_file_perms;
allow exim_t exim_spool_t:dir rw_dir_perms;
allow exim_t exim_spool_t:file create_file_perms;

# /usr/sbin/exim asks for w access to utmp, but it will operate
# correctly without it.  Do not audit write denials to utmp.
#dontaudit exim_t initrc_var_run_t:file { read write };

# When exim runs as user_mail_domain, it needs some extra permissions
# to update /etc/mail/statistics.
#allow user_mail_domain etc_mail_t:file rw_file_perms;

# Silently deny attempts to access /root.
##FIXME:
##dontaudit exim_t sysadm_home_dir_t:dir { getattr search };
##dontaudit system_mail_t sysadm_home_dir_t:dir { getattr search };

# Run procmail in its own domain, if defined.
ifdef(`procmail.te',`
domain_auto_trans(exim_t, procmail_exec_t, procmail_t)
#domain_auto_trans(system_mail_t, procmail_exec_t, procmail_t)
')

# exim -q 
#@allow system_mail_t exim_spool_t:dir rw_dir_perms;
#@allow system_mail_t exim_spool_t:file create_file_perms;

# Inherit and use pipes created by rc scripts.
#@allow system_mail_t initrc_t:fd use;
#@allow system_mail_t initrc_t:fifo_file { getattr read write };

r_dir_file(exim_t, etc_exim_t)
# searches /proc/net/if_inet6 to check ipv6 existence
allow system_crond_t exim_exec_t:file r_file_perms;
# ?
#domain_auto_trans(sysadm_mail_t, exim_exec_t, exim_t)
# ?
domain_auto_trans(initrc_t, exim_exec_t, exim_t)
# hmm - startup
allow exim_t etc_t:lnk_file read;
# checks /var/spool/exim existence
allow exim_t var_spool_t:dir search;
# call ourselves
allow exim_t exim_exec_t:file execute_no_trans;
# hm
allow exim_t sbin_t:dir search;

allow exim_t etc_aliases_t:file r_file_perms;

# huh?
#allow exim_t var_t:dir getattr

# awww
allow exim_t self:capability  dac_override ;
#allow exim_t self:capability { dac_override dac_read_search };

Re: please offer your good advices / new policies: exim, dovecot, maradns, (aptitude)

[Russell Coker]

In future, could you please split long messages into several shorter messages 
with topics to match?  This makes it easier for people to track threads, and 
sometimes I just don't have the time to respond to a long message...

On Thu, 24 Apr 2003 02:06, Peter Gervai wrote:
> Other question: what is the advised way to have the server an admin
> (staff_t?) who is able to create/delete users? Probably emitting user_u
> users are okay in the beginning, because I believe everything more would
> require policy reloading. (I'm checking this after this email anyway, but
> maybe you're faster.)

Anything other than user_u users does require a new policy to be loaded.

An interim solution assuming that you have a basic trust in those 
administrators is to do:
domain_auto_trans(staff_t, useradd_exec_t, useradd_t)
role staff_r types useradd_t;

Now a hostile user with this access could use userdel to remove the 
administrative account, recreate it with a different password, and then login 
for full access.  If you are just protecting against mistakes, tricks, etc 
then it may be OK.

What we probably need is two types of useradd wrapper (similar to the spasswd 
and sadminpasswd distinction).  Then for less priviledged users they won't be 
able to create or remove accounts outside certain UID/GID ranges.

NB  useradd_t does not have setuid capability.  So if the staff_r user does 
not have access to UID=0 and you want a SUID root useradd then you will need 
to add the setuid capability to useradd_t.

Also consider creating a new type for /usr/bin/suseradd so that a staff_r user 
can run useradd but not userdel.

-- 
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: please offer your good advices / new policies: exim, dovecot, maradns, (aptitude)

[Russell Coker]

In regard to your policy patch:
+# run init scripts? valid? secure?? --<g>
+#domain_auto_trans(sysadm_t, etc_t, initrc_t)

Not secure as it may allow the administrator to be tricked into running the 
daemon.  Also it does not allow role transition to system_r and the daemon 
domains would need to be allowed to be in sysadm_r, and it would have the 
daemons running with the identity of the administrative user (bad idea).

+ifdef(`exim.te', `
+allow { crond_t system_crond_t } exim_exec_t:lnk_file read;
+domain_auto_trans(system_crond_t, exim_exec_t, exim_t)
+# FIXME: is this secure?
+domain_auto_trans(crond_t, exim_exec_t, exim_t)
+')

There should be no need for a domain_auto_trans() from crond_t.  As for the 
lnk_file, it's probably best to just have the .fc file not label sym-links.

+# can start exim --<g>
+ifdef(`exim.te', `
+domain_auto_trans_read(dhcpc_t, exim_exec_t, exim_t)
+')
I don't think that this is the right way to do it.  On my laptop I have a 
script running as system_u:system_r:initrc_t that listens on a named pipe.  
When an IP address is assigned then that script is informed by the pipe and 
it will start the necessary daemons.

But I think that the correct way to do this is through a modified cron.  It's 
something I plan to work on when I have some spare time.  Modifying cardctl, 
dhcpc, and ppp policies to separately support this makes no sense to me.

-/var/run/dhclient\.pid         system_u:object_r:var_run_dhcpc_t
+/var/run/dhclient\.(.+\.)?pid          system_u:object_r:var_run_dhcpc_t
What does this do?

For port 53, I think that having the name always be named_port_t is the 
correct thing to do.  It allows the possibility of running two different DNS 
servers on different IP addresses, and also allows having the policy for 
multiple DNS servers to be loaded at the same time to allow an easy 
transition between server programs.  I suggest doing what was done for the 
POP port.

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

several wee things about exim and macros (was: please offer your good advices...)

[Peter Gervai]

On Thu, Apr 24, 2003 at 01:29:03PM +1000, Russell Coker wrote:
> In regard to your policy patch:
> +# run init scripts? valid? secure?? --<g>
> +#domain_auto_trans(sysadm_t, etc_t, initrc_t)
> 
> Not secure as it may allow the administrator to be tricked into running the 
> daemon.  Also it does not allow role transition to system_r and the daemon 
> domains would need to be allowed to be in sysadm_r, and it would have the 
> daemons running with the identity of the administrative user (bad idea).

I miss a FAQ in regards of utilities (and, in fact, in the next few days I
hope to be able to browse through the last months of the mailing list and
distill the answers), in this case run_init. I wasn't aware of its
existence, and thus I was unable to figure out what is the way to start the
daemons. 

Disregard the foul try I did up there. Correct way is (I s'ppose) to do

run_init /etc/init.d/exim start

> +# can start exim --<g>
> +ifdef(`exim.te', `
> +domain_auto_trans_read(dhcpc_t, exim_exec_t, exim_t)
> +')
> I don't think that this is the right way to do it. 

This was another hopeless try. Doesn't work anyway.

> On my laptop I have a 
> script running as system_u:system_r:initrc_t that listens on a named pipe.  
> When an IP address is assigned then that script is informed by the pipe and 
> it will start the necessary daemons.

problem is that - as I mentioned in my email last week to you - dhcpcd does
_not_ start anything. like:

  116    298 system_u:system_r:dhcpc_t                [dhclient]
  199    303 system_u:system_r:syslogd_t              [syslogd]
  202    304 system_u:system_r:klogd_t                [klogd]
  216    307 system_u:system_r:httpd_t                [apache2]
  218    307 system_u:system_r:httpd_t                 \_ [apache2]
  219    307 system_u:system_r:httpd_t                 \_ [apache2]
[...]
  228    309 system_u:system_r:dovecot_master_t       [dovecot]
  245    313 system_u:system_r:dovecot_authdaemon_t    \_ [dovecot-auth]
  246    314 system_u:system_r:dovecot_imap_t          \_ [imap-login]
  247    314 system_u:system_r:dovecot_imap_t          \_ [imap-login]
  248    314 system_u:system_r:dovecot_imap_t          \_ [imap-login]
  250    315 system_u:system_r:dovecot_pop_t           \_ [pop3-login]
  251    315 system_u:system_r:dovecot_pop_t           \_ [pop3-login]
  252    315 system_u:system_r:dovecot_pop_t           \_ [pop3-login]
  234    310 system_u:system_r:inetd_t                [inetd]
  241    312 system_u:system_r:sshd_t                 [sshd]
 5584    312 system_u:system_r:sshd_t                  \_ [sshd]
[...]

it is no way related to the processes, but still receives the packet_socket
recv events for everybody. As far as I know the startup goes on initrc_t,
starts dhcpcd, it obtains IP address, then the system goes on and starts
other rc.d scripts, including exim, apache, whatever. And still, dhcpcd gets
the receive events because it somehow "owns"(???) the interface. (Can I see
contexts of the interfaces? ...if there is such a thing.)

> -/var/run/dhclient\.pid         system_u:object_r:var_run_dhcpc_t
> +/var/run/dhclient\.(.+\.)?pid          system_u:object_r:var_run_dhcpc_t
> What does this do?

grin@latyak:~$ ls -la --con /var/run/dh*
-rw-r--r--  root     root     system_u:object_r:var_run_dhcpc_t /var/run/dhclient.eth0.pid

> For port 53, I think that having the name always be named_port_t is the 
> correct thing to do.  It allows the possibility of running two different DNS 
> servers on different IP addresses, and also allows having the policy for 
> multiple DNS servers to be loaded at the same time to allow an easy 
> transition between server programs.  I suggest doing what was done for the 
> POP port.

Sounds logical, I'll change the policy as time permits. However I'd like to
note that port 53 is called 'domain' by /etc/services, and not 'named'.

Peter

--
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: several wee things about exim and macros (was: please offer your good advices...)

[Russell Coker]

On Thu, 24 Apr 2003 21:00, Peter Gervai wrote:
> > For port 53, I think that having the name always be named_port_t is the
> > correct thing to do.  It allows the possibility of running two different
> > DNS servers on different IP addresses, and also allows having the policy
> > for multiple DNS servers to be loaded at the same time to allow an easy
> > transition between server programs.  I suggest doing what was done for
> > the POP port.
>
> Sounds logical, I'll change the policy as time permits. However I'd like to
> note that port 53 is called 'domain' by /etc/services, and not 'named'.

Sounds reasonable.  Maybe we should change it to domain_port_t or something 
similar, and change the other things to match /etc/services in some way.

-- 
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: please offer your good advices / new policies: exim, dovecot, maradns, (aptitude)

[Stephen Smalley]

On Wed, 2003-04-23 at 12:06, Peter Gervai wrote:
> There was a question a month ago about dhcpc_t (and sshd_t and newrole_t in
> cases) emitting this:
> 
> avc:  denied  { recvfrom } for  pid=1059 exe=/usr/sbin/exim saddr=10.1.1.16
>  source=17664 daddr=10.1.1.1 dest=60 netif=eth0
>  scontext=system_u:system_r:dhcpc_t tcontext=root:sysadm_r:sysadm_t
>  tclass=packet_socket
> 
> (One line for every packet ever arriving on the network!)

SELinux checks recvfrom permission between the socket and the packet
just before the packet is queued on the receiving socket; the hook is
security_sock_rcv_skb in sock_queue_rcv_skb in include/net/sock.h in the
2.4 tree.  Since dhcpc is using a packet socket, every packet reaches
this point, although it may be filtering them after the check via a
socket filter.  Note that the example policy grants this permission to
netmsg_eth0_t, the default type for incoming packets on eth0.  Locally
generated packets would show up with the domain of the sending socket
(== domain of the process that created the sending socket).  You can
probably just 'allow dhcpc_t domain:packet_socket recvfrom;'.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: please offer your good advices / new policies: exim, dovecot, maradns, (aptitude)

[Stephen Smalley]

On Wed, 2003-04-23 at 16:13, Andreas Schuldei wrote:
> yes, that is what i did, too. (i think i asked the same question
> here, too, and never got an answer.)

Since they use a packet socket, they receive every frame, so SELinux is
correctly checking permission.  They may be filtering the packets via a
socket filter after the permission check has been performed.

> i have here collected over time:
> dontaudit dhcpd_t sshd_t:packet_socket { recvfrom };

It would be simpler to do 'dontaudit dhcpd_t domain:packet_socket
recvfrom;' or 'allow dhcpd_t domain:packet_socket recvfrom;'.  Not clear
it is worth denying this access for locally generated packets, when it
is still free to pick up remote ones (and you can't distinguish among
the remote ones except by interface unless you are using the
experimental labeled networking support). 

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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