Domain Transitions (or the Exim4 policy)

Domain Transitions (or the Exim4 policy)

[Shane Wegner]

Hi all,

I am new to this list and SELinux in general but have
managed to get it running on a Debian cid system using
Russell's packages and policies.  Those policies did come
with a sendmail policy which I have attempted to modify for
exim4.  I believe I have the file permissions pretty much
figured out but the domain transitions are a bit confusing.

The two things I am not sure of is when exim calls
procmail, there is a domain transition to procmail_t which
is rather restrictive.  My own personal .procmailrc file
for example runs tmda which is a python program which in
turn can send out response emails.  procmail_t by default
doesn't want any part of this and when procmail calls
sendmail which is a symbolic link back to exim4, there is
no transition back to exim4_t so exim doesn't have the
permissions it needs.  Further, when a user sends mail, say
echo Hello world |mail
exim4 gets spawned but this time in the user_t domain,
again without the necessary permissions to write to its
spool.

I'm thinking maybe procmail should run as user_r:user_t as
a users procmail process should be able to do anything the
logged in user can do.  Would that be a better way of doing
things?  Also, how would I set it up so that whenever a
user, cron, or any other process for that matter called
exim4 or sendmail, it took it into the exim4_t domain?

For anyone who is interested, I have included exim4.te
below.  Any comments would be appreciated.

#DESC Exim4 - Mail server
#
# Adapted from sendmail.te by Shane Wegner <shane@cm.nu>
# sendmail.te Authors:  Stephen Smalley <sds@epoch.ncsc.mil> and Timothy Fraser  
# X-Debian-Packages: exim4-daemon-heavy
# Depends: mta.te
#

#################################
#
# Rules for the exim4_t domain.
#
# exim4_t is the domain for the exim4 
# daemon started by the init rc scripts.
#

daemon_domain(exim4, `, mta_delivery_agent, mail_server_domain')

tmp_domain(exim4)
log_domain(exim4)

allow initrc_t exim4_exec_t:lnk_file read;

# Use capabilities
allow exim4_t self:capability { chown dac_override fowner setuid setgid sys_resource net_bind_service };
allow exim4_t self:process setpgid;

# Use the network.
can_network(exim4_t)
allow exim4_t resolv_conf_t:file { getattr read };

allow exim4_t self:unix_stream_socket create_stream_socket_perms;
allow exim4_t self:unix_dgram_socket create_socket_perms;
# TODO: Does exim use fifos?
allow exim4_t self:fifo_file rw_file_perms;

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

allow exim4_t etc_t:file { getattr read };

allow exim4_t etc_aliases_t:file { getattr r_file_perms };
allow exim4_t exim4_conf_t:dir rw_dir_perms;
allow exim4_t exim4_conf_t:file create_file_perms;
# for the start script to generate exim4.config
# from /etc/exim4/conf.d fragments
allow initrc_t exim4_conf_t:dir rw_dir_perms;
allow initrc_t exim4_conf_t:file create_file_perms;

# Write to /var/spool/mail and /var/spool/exim4
allow exim4_t var_spool_t:dir search;
allow exim4_t exim4_spool_t:dir { read getattr lock search ioctl add_name remove_name write rmdir };
allow exim4_t exim4_spool_t:file { create ioctl read getattr lock write setattr append link unlink rename };
allow exim4_t mail_spool_t:dir rw_dir_perms;
allow exim4_t mail_spool_t:file create_file_perms;

#allow exim4_t lib_t:file { getattr read };

# Run procmail in its own domain, if defined.
ifdef(`procmail.te',`
domain_auto_trans(exim4_t, procmail_exec_t, procmail_t)
allow exim4_t bin_t:dir { getattr search };
')

allow exim4_t sysctl_kernel_t:dir search;
allow exim4_t sysctl_kernel_t:file { getattr read };
allow exim4_t random_device_t:chr_file read;

ifdef(`clamav.te', `
# Comment these directives if not using clam from an acl or if
# Exim is not otherwise directly connecting to clamd.
can_unix_connect(exim4_t, clamd_var_run_t)
allow exim4_t clamd_var_run_t:sock_file { write };
dontaudit clamd_t var_spool_t:dir { search };
allow clamd_t exim4_spool_t:dir { search };
allow clamd_t exim4_spool_t:file { getattr read };
')

ifdef(`mailman.te', `
# Recommended Debian Exim ACLs check for a mailing list
# by the existance of its config file in mailman_data_t
allow exim4_t mailman_data_t:file { getattr read };
')

#domain_auto_trans(initrc_t, exim4_exec_t, exim4_t)
#allow initrc_t exim4_exec_t:lnk_file read;
allow exim4_t exim4_exec_t:file execute_no_trans;
allow exim4_t sbin_t:dir search;

--
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: Domain Transitions (or the Exim4 policy)

[Russell Coker]

On Fri, 19 Dec 2003 13:45, Shane Wegner <shane-keyword-selinux.9d5a25@cm.nu> 
wrote:
> I am new to this list and SELinux in general but have
> managed to get it running on a Debian cid system using
> Russell's packages and policies.  Those policies did come
> with a sendmail policy which I have attempted to modify for
> exim4.  I believe I have the file permissions pretty much
> figured out but the domain transitions are a bit confusing.

Why did you change it to exim4_t?  It seems to me that as exim and sendmail 
operate in the same manner it would be better to have a single policy to use 
for them both.  This will make it easier to maintain the policy.

> The two things I am not sure of is when exim calls
> procmail, there is a domain transition to procmail_t which
> is rather restrictive.  My own personal .procmailrc file
> for example runs tmda which is a python program which in
> turn can send out response emails.  procmail_t by default
> doesn't want any part of this and when procmail calls
> sendmail which is a symbolic link back to exim4, there is
> no transition back to exim4_t so exim doesn't have the

It should transition to system_mail_t.

> permissions it needs.  Further, when a user sends mail, say
> echo Hello world |mail
> exim4 gets spawned but this time in the user_t domain,
> again without the necessary permissions to write to its
> spool.

In the sendmail policy it would transition to user_mail_t domain.

> I'm thinking maybe procmail should run as user_r:user_t as
> a users procmail process should be able to do anything the
> logged in user can do.  Would that be a better way of doing
> things?

Then if someone manages to take control over procmail they get complete access 
to your account.

-- 
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: Domain Transitions (or the Exim4 policy)

[Shane Wegner]

On Fri, Dec 19, 2003 at 04:47:45PM +1100, Russell Coker wrote:
> Why did you change it to exim4_t?  It seems to me that as exim and sendmail 
> operate in the same manner it would be better to have a single policy to use 
> for them both.  This will make it easier to maintain the policy.

Point taken.  Exim does seem to use a slightly different
capability set and needs some modified permissions but
they're trivial changes.

> > permissions it needs.  Further, when a user sends mail, say
> > echo Hello world |mail
> > exim4 gets spawned but this time in the user_t domain,
> > again without the necessary permissions to write to its
> > spool.
> 
> In the sendmail policy it would transition to user_mail_t domain.

After adapting sendmail.te and putting that in per your
suggestion, it does indeed transition to user_mail_t though
I can't figure out how.  The problem I'm seeing now though
is from user_mail_t, exim doesn't have permission to wread
its config files.  Do I need to give user_mail_t or
user_mail_domain all the privileges given to sendmail_t in
the sendmail policy?  Also, is user_mail_t an alias for
some other domain.  I'm seeing user_mail_domain in policies
but don't see user_mail_t anywhere save a minor mention
in attrib.te.

Thanks for the suggestions, they were of great help.

Shane

--
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: Domain Transitions (or the Exim4 policy)

[Russell Coker]

On Fri, 19 Dec 2003 18:09, Shane Wegner <shane-dated-1074409746.778e04@cm.nu> 
wrote:
> On Fri, Dec 19, 2003 at 04:47:45PM +1100, Russell Coker wrote:
> > Why did you change it to exim4_t?  It seems to me that as exim and
> > sendmail operate in the same manner it would be better to have a single
> > policy to use for them both.  This will make it easier to maintain the
> > policy.
>
> Point taken.  Exim does seem to use a slightly different
> capability set and needs some modified permissions but
> they're trivial changes.

Send me a list.

I think that possibly the solution to this is to have sendmail.te and exim.te 
both instantiate a common macro for 99% of the policy.

> > > permissions it needs.  Further, when a user sends mail, say
> > > echo Hello world |mail
> > > exim4 gets spawned but this time in the user_t domain,
> > > again without the necessary permissions to write to its
> > > spool.
> >
> > In the sendmail policy it would transition to user_mail_t domain.
>
> After adapting sendmail.te and putting that in per your
> suggestion, it does indeed transition to user_mail_t though
> I can't figure out how.  The problem I'm seeing now though

sendmail_macros.te

> is from user_mail_t, exim doesn't have permission to wread
> its config files.  Do I need to give user_mail_t or

Which files?

> user_mail_domain all the privileges given to sendmail_t in
> the sendmail policy?

Many of those privs, hopefully as few as possible.

> Also, is user_mail_t an alias for
> some other domain.  I'm seeing user_mail_domain in policies
> but don't see user_mail_t anywhere save a minor mention
> in attrib.te.

It's in mta_macros.te.  user_mail_domain is for all of user_mail_t, 
staff_mail_t, 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: Domain Transitions (or the Exim4 policy)

[David A. Caplan]

Shane Wegner wrote:
>
>  it does indeed transition to user_mail_t though
> I can't figure out how.  

For future reference, I'd suggest the Reverse Domain Transition analysis 
function in apol (http://www.tresys.com/selinux/) to easily find the 
exact rules in policy.conf that allow a domain to transition to the 
domain in question.

In regard to your other question:
 > I'm seeing user_mail_domain in policies
 > but don't see user_mail_t anywhere save a minor mention
 > in attrib.te.

You can also use apol to find all TE rules related to a type and include 
those rules using the type's attributes by using the Include Indirect 
Matches option under the Policy Rules tab in apol.  The search results 
also provide hyper links into policy.conf so you can trace back where 
the rules came from.  The Policy Components tab can show you all the 
types that use a given attribute.

David
-- 
__________________________________

David Caplan     410 290 1411 x105
dac@tresys.com
Tresys Technology, LLC
8840 Stanford Blvd., Suite 2100
Columbia, MD 21045


--
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: Domain Transitions (or the Exim4 policy)

[Shane Wegner]

On Fri, Dec 19, 2003 at 06:59:56PM +1100, Russell Coker wrote:
> On Fri, 19 Dec 2003 18:09, Shane Wegner <shane-dated-1074409746.778e04@cm.nu> 
> wrote:
> > On Fri, Dec 19, 2003 at 04:47:45PM +1100, Russell Coker wrote:
> > > Why did you change it to exim4_t?  It seems to me that as exim and
> > > sendmail operate in the same manner it would be better to have a single
> > > policy to use for them both.  This will make it easier to maintain the
> > > policy.
> >
> > Point taken.  Exim does seem to use a slightly different
> > capability set and needs some modified permissions but
> > they're trivial changes.
> 
> Send me a list.
> 
> I think that possibly the solution to this is to have sendmail.te and exim.te 
> both instantiate a common macro for 99% of the policy.

Ok, differences I can spot are:
Exim needs only read access to sendmail_conf_t it its case
/etc/exim4 and /var/lib/exim4
Init scripts need write access to /var/lib/exim4 as the
main config file automatically gets generated from
fragments on startup/reload.
Needs read access to /dev/urandom
Needs append-only access to sendmail_log_t  In exim's case,
it's a directory (/var/log/exim4).
Needs complete access to sendmail_mqueue_t including
mkdir/rmdir/file locking etc.  That's exim's playground.
Needs read access to /home or /home/(^/+)/.procmailrc.  The
procmail filter checks for the existance of a user's
.procmailrc file which is how it decides whether to use
procmail as the delivery agent or if not found, it delivers
to the mail spool directly.  I suppose it'd also need
$HOME/.forward etc.

Capabilities Exim uses which the sendmail.te doesn't
currently allow: dac_override fowner sys_resource.

Sendmail allows sys_nice and sys_tty_config which Exim does
not appear to use.  Exim also needs a line similar to:
allow sendmail_t self:process setpgid;

Best,
Shane

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