thanks, and new issue

thanks, and new issue

[Shaun Savage]

HI

Thanks, when I did a "make load" that fixed the newrole problem.

New Issue:

I am trying to add/make a new security policy for the courier mail 
server.  Sendmail is easy compared with qmail or courier.  This will 
also be a good learning experiance for me (and others) to go through the 
thinking behind creating a security policy.    I am not a courier 
expert,   but I think selinux and courier would be good togther.

The problem is how fine grained a security policy I should make?
Should every processes have a seperate policy or should the whole 
package be one security?
Should the certs be protected more than other parts?
Courier writes to the users Maildir in their home dir, only 
courier_local writes to users dir.  ????



Background:
Courier is a all inclusive mails server.  It is like qmail with 
different processes doing different tasks. It also has imap,pop3 secure 
imap,pop3 also.  It has a web interface to help with configuration.  And 
webmail client.

File structure
/etc/courier                courier_conf_t        configuration files

/var/spool/courier      courier_spool_t      spool directories for courier
/var/spool/courier/msgq    courier_msgq_t
/var/spool/courier/msgs     courier_msgs_t
/var/spool/courier/authdaemon

/usr/lib/courier          courier_t                 courier
/usr/lib/courier/bin    courier_bin_t
/usr/lib/courier/sbin   courier_sbin_t
/usr/lib/courier/share  courier_share_t
/usr/lib/courier/share/rootcerts    courier_certs_t               esmtp, 
imap, pop3 certs for SSL
/usr/lib/courier/share/htmldoc

Running processes:

courierd            main daemon            courier_daemon_t
courierXXXX   transport daemons    courier_trans_t
courieresmtp    input daemon             courier_esmtp_t
authdaemon      authorize connections courier_auth_t
couriertcpd       courier tcpd                  courier_tcpd_t
pop3d, pop3d-ssl, imapd, imapd-ssl       courier_XXXX_t
courierfilter      spam killer   (not used now)  courier_filter_t







--
You have received this message because you are subscribed to the selinux 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: thanks, and new issue

[Stephen Smalley]

On Thu, 13 Dec 2001, Shaun Savage wrote:

> I am trying to add/make a new security policy for the courier mail
> server.  Sendmail is easy compared with qmail or courier.  This will
> also be a good learning experiance for me (and others) to go through the
> thinking behind creating a security policy.    I am not a courier
> expert,   but I think selinux and courier would be good togther.

I am not familiar with courier, but I'll try to provide some general
guidance below.  Also, just FYI, please note that the sendmail domain
is just a starting point for sendmail; a more complete solution for
sendmail is being developed by some folks at MITRE.

> The problem is how fine grained a security policy I should make?
> Should every processes have a seperate policy or should the whole
> package be one security?
> Should the certs be protected more than other parts?
> Courier writes to the users Maildir in their home dir, only
> courier_local writes to users dir.  ????

This depends on the permissions required by each courier-related process
and your security goals.  If several processes require essentially the
same permissions, then you can place them in the same domain.  Likewise,
if several directories/files should be accessible in the same way by the
same processes, you can place them in the same type.  If you aren't sure
what permissions are required, you can initially define separate domains
for each process, run the system in permissive mode to collect audit
messages, and then evaluate the resulting messages to see whether some of
the domains should be coalesced.  The script posted by Justin Smith may be
helpful to you in automatically converting the audit messages to allow
rules, but you still need to carefully analyze these rules to see if they
meet your security goals.

You should be cautious about using separate types for individual files
within a single directory, although this is possible.  The problem with
using separate types for individual files within a single directory is
ensuring that the type is preserved if the file is subsequently updated.
If the existing file is merely modified in place, then the type will be
preserved.  However, if the update to the file involves creation of a new
file, then you must take steps to ensure that the type of the new file is
the same as the type of the original.  One approach for doing so is to put
programs that update the file into a separate domain and defining a
file_type_auto_trans rule for that domain so that files created by the
domain in the directory will inherit the desired type rather than the type
of the parent directory by default.  However, if the program creates
multiple files in the same directory that must have different types, this
approach will not work, so you will have to either modify the program or
wrap it with another program that sets the file types properly.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.