All of lore.kernel.org
 help / color / mirror / Atom feed
* first pass at a spamassassin/spamc/spamd policy
@ 2003-07-15 18:56 Colin Walters
  2003-07-16  1:10 ` Russell Coker
  0 siblings, 1 reply; 4+ messages in thread
From: Colin Walters @ 2003-07-15 18:56 UTC (permalink / raw)
  To: selinux; +Cc: Russell Coker

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

Hi,

Attached is a first attempt at a spamassassin policy.  It is not going
to be sufficient for most typical users though, because we don't
currently have a clean way to transition from procmail_t to e.g.
user_spamc_t.

Russell and I discussed this issue on IRC last night, and he was of the
opinion that we should create a shell script wrapper for procmail which
looked at the type of the home directory of the user we're delivering
to, and computing and transitioning to a new type (e.g. user_procmail_t)
based on that.  Once that's in place, we would have a rule like:

ifdef(`procmail.te',`
domain_auto_trans($1_procmail_t, spamc_exec_t, $1_spamc_t)
')
in spamassassin_macros.te.

One other issue I ran into; what's a good way to specify that a program
may interact with the user?  Right now I'm doing:

allow $1_$2_t privfd:fd use;
allow $1_$2_t userpty_type:chr_file rw_file_perms;

But this seems a bit unclean.  Any suggestions?



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

#
# Macros for spamassassin domains.
#
# Author: Colin Walters <walters@verbum.org>

# spamassassin_domain(domain_prefix)
#
# Define derived domains for various spamassassin tools when executed
# by a user domain.
#
# The type declarations for the executable types of these programs are
# provided separately in domains/program/spamassassin.te and
# domains/program/spamc.te.
#
undefine(`spamassassin_domain')
ifdef(`spamassassin.te', `define(`using_spamassassin', `')')
ifdef(`spamd.te', `define(`using_spamassassin', `')')
ifdef(`spamc.te', `define(`using_spamassassin', `')')

ifdef(`using_spamassassin',`

#######
# Macros used internally in these spamassassin macros.
#

###
# Define a domain for a spamassassin-like program (spamc/spamassassin).
#
# Note: most of this should really be in a generic macro like
# base_user_program($1, foo)
define(`spamassassin_program_domain',`
type $1_$2_t, domain, privlog;
domain_auto_trans($1_t, $2_exec_t, $1_$2_t)

role $1_r types $1_$2_t;
general_domain_access($1_$2_t)

base_file_read_access($1_$2_t)
normal_config_file_read_access($1_$2_t)
uses_shlib($1_$2_t)
read_locale($1_$2_t)
dontaudit $1_$2_t var_t:dir search;
allow $1_$2_t privfd:fd use;
allow $1_$2_t userpty_type:chr_file rw_file_perms;
') dnl end spamassassin_program_domain

###
# Give privileges to a domain for accessing ~/.spamassassin
# and a few other misc things like /dev/random.
# This is granted to /usr/bin/spamassassin and
# /usr/sbin/spamd, but NOT spamc (because it does not need it).
#
define(`spamassassin_agent_privs',`
allow $1 { home_root_t user_home_dir_type sysadm_home_dir_t }:dir { search getattr };
file_type_auto_trans($1, $2_home_dir_t, $2_home_spamassassin_t)
create_dir_file($1, $2_home_spamassassin_t)

allow $1 random_device_t:chr_file r_file_perms;
')

#######
# Define the main spamassassin macro.  This itself creates a
# domain for /usr/bin/spamassassin, and also spamc/spamd if
# applicable.
#
define(`spamassassin_domain',`
spamassassin_program_domain($1, spamassassin)

# For perl libraries.
allow $1_spamassassin_t lib_t:file rx_file_perms;
# Ignore perl digging in /proc and /var.
dontaudit $1_spamassassin_t proc_t:dir search;
dontaudit $1_spamassassin_t { sysctl_t sysctl_kernel_t }:dir search;

# The type of ~/.spamassassin
type $1_home_spamassassin_t, file_type, sysadmfile;
create_dir_file($1_t, $1_home_spamassassin_t)
allow $1_t $1_home_spamassassin_t:notdevfile_class_set { relabelfrom relabelto };
allow $1_t $1_home_spamassassin_t:dir { relabelfrom relabelto };

spamassassin_agent_privs($1_spamassassin_t, $1)

# Uncomment if you have spamassassin do DNS lookups
#can_network($1_spamassassin_t)

###
# Define the domain for /usr/bin/spamc
#
ifdef(`spamc.te',`
spamassassin_program_domain($1, spamc)
can_network($1_spamc_t)

# Allow connecting to a local spamd
ifdef(`spamd.te',`
can_tcp_connect($1_spamc_t, spamd_t)
') dnl endif spamd.te
') dnl endif spamc.te

###
# Define the domain for /usr/sbin/spamd
#
ifdef(`spamd.te',`

spamassassin_agent_privs(spamd_t, $1)

') dnl endif spamd.te

') dnl end spamassassin_domain

', `

define(`spamassassin_domain',`')

')

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

#DESC SpamAssassin
#
# Author: Colin Walters <walters@debian.org>
# X-Debian-Packages: spamassassin

type spamassassin_exec_t, file_type, sysadmfile, exec_type;

# Everything else is in spamassassin_macros.te.

[-- Attachment #4: spamc.te --]
[-- Type: text/plain, Size: 222 bytes --]

#DESC Spamc - Spamassassin client
#
# Author: Colin Walters <walters@debian.org>
# X-Debian-Packages: spamc
#

type spamc_exec_t, file_type, sysadmfile, exec_type;

# Everything else is in spamassassin_macros.te.

[-- Attachment #5: spamd.te --]
[-- Type: text/plain, Size: 1025 bytes --]

#DESC Spamd - Spamassassin daemon
#
# Author: Colin Walters <walters@debian.org>
# X-Debian-Packages: spamassassin
#

daemon_domain(spamd)

tmp_domain(spamd)
allow spamd_t tmp_t:dir { getattr read };

type spamd_port_t, port_type;
allow spamd_t spamd_port_t:tcp_socket name_bind;

general_domain_access(spamd_t)
base_file_read_access(spamd_t)
normal_config_file_read_access(spamd_t)
uses_shlib(spamd_t)

# Various Perl bits
allow spamd_t lib_t:file rx_file_perms;
dontaudit spamd_t { sysctl_t sysctl_kernel_t }:dir search;
dontaudit spamd_t { shadow_t }:file read;
dontaudit spamd_t sysadm_devpts_t:chr_file { read write };
dontaudit spamd_t initrc_var_run_t:file { read write lock };

can_network(spamd_t)
allow spamd_t self:capability { net_bind_service };

# Spamassassin, when run as root and using per-user config files,
# setuids to the user running spamc.  Comment this if you are not
# using this ability.
allow spamd_t self:capability { setuid setgid dac_override dac_read_search };

[-- Attachment #6: spamassassin-general.patch --]
[-- Type: text/plain, Size: 1009 bytes --]

--- policy-1.0/macros/user_macros.te	2003-07-07 09:19:28.000000000 -0400
+++ selinux-policy-1.0/macros/user_macros.te	2003-07-15 03:04:34.000000000 -0400
@@ -155,6 +155,7 @@
 ifdef(`crontab.te', `crontab_domain($1)')
 ifdef(`ssh.te', `ssh_domain($1)')
 ifdef(`irc.te', `irc_domain($1)')
+ifdef(`using_spamassassin', `spamassassin_domain($1)')
 ifdef(`uml.te', `uml_domain($1)')
 ifdef(`clamav.te', `user_clamscan_domain($1)')
 ifdef(`fingerd.te', `fingerd_macro($1)')
--- policy-1.0/net_contexts	2003-07-10 10:44:59.000000000 -0400
+++ selinux-policy-1.0/net_contexts	2003-07-15 13:27:56.000000000 -0400
@@ -75,6 +75,7 @@
 portcon udp 5323 system_u:object_r:imaze_port_t
 ')
 ifdef(`ircd.te', `portcon tcp 6667 system_u:object_r:ircd_port_t')
+ifdef(`spamd.te', `portcon tcp 783 system_u:object_r:spamd_port_t')
 ifdef(`apache.te', `define(`use_http_cache')')
 ifdef(`squid.te', `define(`use_http_cache')')
 ifdef(`use_http_cache', `portcon tcp 8080  system_u:object_r:http_cache_port_t')

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: first pass at a spamassassin/spamc/spamd policy
  2003-07-15 18:56 first pass at a spamassassin/spamc/spamd policy Colin Walters
@ 2003-07-16  1:10 ` Russell Coker
  2003-07-16  7:59   ` Colin Walters
  0 siblings, 1 reply; 4+ messages in thread
From: Russell Coker @ 2003-07-16  1:10 UTC (permalink / raw)
  To: Colin Walters, selinux

On Wed, 16 Jul 2003 04:56, Colin Walters wrote:
> Attached is a first attempt at a spamassassin policy.  It is not going
> to be sufficient for most typical users though, because we don't
> currently have a clean way to transition from procmail_t to e.g.
> user_spamc_t.
>
> Russell and I discussed this issue on IRC last night, and he was of the
> opinion that we should create a shell script wrapper for procmail which

I was thinking of a wrapper written in C which is compiled.  Do we even have 
enough utility programs to allow such things to be written in shell scripts?

> ifdef(`procmail.te',`
> domain_auto_trans($1_procmail_t, spamc_exec_t, $1_spamc_t)
> ')
> in spamassassin_macros.te.
>
> One other issue I ran into; what's a good way to specify that a program
> may interact with the user?  Right now I'm doing:
>
> allow $1_$2_t privfd:fd use;
> allow $1_$2_t userpty_type:chr_file rw_file_perms;
>
> But this seems a bit unclean.  Any suggestions?

When you have the wrapper as discussed you just need the following:
allow $1_$2_t privfd:fd use;
allow $1_$2_t { $1_devpts_t $1_tty_device_t }:chr_file rw_file_perms;

Also another possibility is for the wrapper program to change the type of the 
terminal device in a similar manner to newrole and then change it back after 
the program is complete.  Then the program can't run amok on terminals from 
other sessions by the same user.

tmp_domain(spamd)
allow spamd_t tmp_t:dir { getattr read };
The second line should not be needed, the first line should do it.

# Note: most of this should really be in a generic macro like
# base_user_program($1, foo)

Good idea.  Please send me a patch and convert some of the policy to using it 
as an example.  ;)

file_type_auto_trans($1, $2_home_dir_t, $2_home_spamassassin_t)
create_dir_file($1, $2_home_spamassassin_t)

The first line does everything that the second line does.  Also consider 
whether you need the full capabilities of the file_type_auto_trans() macro, 
does spamassasin really need to create sockets under the user home directory?
Maybe the following will do:
file_type_auto_trans($1, $2_home_dir_t, $2_home_spamassassin_t, file)

I've put spamd.te in my tree.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: first pass at a spamassassin/spamc/spamd policy
  2003-07-16  1:10 ` Russell Coker
@ 2003-07-16  7:59   ` Colin Walters
  2003-07-16  8:24     ` Russell Coker
  0 siblings, 1 reply; 4+ messages in thread
From: Colin Walters @ 2003-07-16  7:59 UTC (permalink / raw)
  To: Russell Coker; +Cc: selinux

On Tue, 2003-07-15 at 21:10, Russell Coker wrote:

> I was thinking of a wrapper written in C which is compiled. 

That would make more sense, yeah.

>  Do we even have 
> enough utility programs to allow such things to be written in shell scripts?

I guess I was mainly thinking of "runas", but we might need more than
that.

> When you have the wrapper as discussed you just need the following:
> allow $1_$2_t privfd:fd use;
> allow $1_$2_t { $1_devpts_t $1_tty_device_t }:chr_file rw_file_perms;

Ok, I've done that in my tree.

> Also another possibility is for the wrapper program to change the type of the 
> terminal device in a similar manner to newrole and then change it back after 
> the program is complete.  Then the program can't run amok on terminals from 
> other sessions by the same user.

I dislike this idea; it's OK for newrole because newrole kind of takes
over your terminal with the password prompt and everything.  But it
would be reasonable to run spamassassin and something else
simultaneously.

> tmp_domain(spamd)
> allow spamd_t tmp_t:dir { getattr read };
> The second line should not be needed, the first line should do it.

Ok, hm...I think it wasn't working for me before, but it appears to be
now; perhaps I picked up a fix in a merge with your tree.

> # Note: most of this should really be in a generic macro like
> # base_user_program($1, foo)
> 
> Good idea.  Please send me a patch and convert some of the policy to using it 
> as an example.  ;)

Heh.  There are a number of things I want to do first...but it should go
on the TODO list.

> file_type_auto_trans($1, $2_home_dir_t, $2_home_spamassassin_t)
> create_dir_file($1, $2_home_spamassassin_t)
> 
> The first line does everything that the second line does.  Also consider 
> whether you need the full capabilities of the file_type_auto_trans() macro, 
> does spamassasin really need to create sockets under the user home directory?
> Maybe the following will do:
> file_type_auto_trans($1, $2_home_dir_t, $2_home_spamassassin_t, file)

I don't think that's enough, because I want it to be able to create the
~/.spamassassin directory too.

> I've put spamd.te in my tree.

Cool.


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: first pass at a spamassassin/spamc/spamd policy
  2003-07-16  7:59   ` Colin Walters
@ 2003-07-16  8:24     ` Russell Coker
  0 siblings, 0 replies; 4+ messages in thread
From: Russell Coker @ 2003-07-16  8:24 UTC (permalink / raw)
  To: Colin Walters; +Cc: selinux

On Wed, 16 Jul 2003 17:59, Colin Walters wrote:
> > tmp_domain(spamd)
> > allow spamd_t tmp_t:dir { getattr read };
> > The second line should not be needed, the first line should do it.
>
> Ok, hm...I think it wasn't working for me before, but it appears to be
> now; perhaps I picked up a fix in a merge with your tree.

You probably added the second line first, and then added the tmp_domain() 
entry later.  I've done that a few times myself.

> > file_type_auto_trans($1, $2_home_dir_t, $2_home_spamassassin_t)
> > create_dir_file($1, $2_home_spamassassin_t)
> >
> > The first line does everything that the second line does.  Also consider
> > whether you need the full capabilities of the file_type_auto_trans()
> > macro, does spamassasin really need to create sockets under the user home
> > directory? Maybe the following will do:
> > file_type_auto_trans($1, $2_home_dir_t, $2_home_spamassassin_t, file)
>
> I don't think that's enough, because I want it to be able to create the
> ~/.spamassassin directory too.

I've been thinking of writing a macro that would just allow creation of a 
directory or a file under a particular directory with a type change.

Wanting to create a directory or a file is a really common operation so it 
makes sense for it to be easy to allow it without allowing other things.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-07-16  8:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-15 18:56 first pass at a spamassassin/spamc/spamd policy Colin Walters
2003-07-16  1:10 ` Russell Coker
2003-07-16  7:59   ` Colin Walters
2003-07-16  8:24     ` Russell Coker

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.