postfix_smtp_t

[Christoph Höger]

Hi,

this is a rather special use case, but I think it is valid. According to
Pauls hints at
 http://marilyn.frields.org:8080/~paul/wordpress/?p=2616
I configured postfix to relay my local mail via some mail servers. But
since I like a clean approach I did not want the sasl_password files
in /etc/ so that the admin (me) has to handle plain text passwords
there. 

Postfix seems to support multiple db files at arbitrary positions. But
SELinux does not. I guess the transition to postfix_smtp_t is a little
too early (before chroot). So I changed the context of my sasl_passwd
files to postfix_smtp_t, just to notice that:

1. I (as a user) cannot do this
2. After I did it nevertheless I cannot edit those files

So here is my proposal:

Introduce postfix_userconfig_t and let postfix_smtp_t read it, and allow
transitions and read/write access from unconfined_t to it. I know that
this is suboptimal because it effectively becomes unconfinded_t, but
since the admin _must_ add those files to /etc/postfix/main.cf (and
should allow only harmless files) I guess that this is ok.

any objections or shall I try to write a patch for the policy?

[Daniel J Walsh]

On 07/23/2009 05:03 AM, Christoph Höger wrote:
>  Hi,
>  
>  this is a rather special use case, but I think it is valid. According to
>  Pauls hints at
>   http://marilyn.frields.org:8080/~paul/wordpress/?p=2616
>  I configured postfix to relay my local mail via some mail servers. But
>  since I like a clean approach I did not want the sasl_password files
>  in /etc/ so that the admin (me) has to handle plain text passwords
>  there. 
>  
>  Postfix seems to support multiple db files at arbitrary positions. But
>  SELinux does not. I guess the transition to postfix_smtp_t is a little
>  too early (before chroot). So I changed the context of my sasl_passwd
>  files to postfix_smtp_t, just to notice that:
>  
>  1. I (as a user) cannot do this
>  2. After I did it nevertheless I cannot edit those files
>  
>  So here is my proposal:
>  
>  Introduce postfix_userconfig_t and let postfix_smtp_t read it, and allow
>  transitions and read/write access from unconfined_t to it. I know that
>  this is suboptimal because it effectively becomes unconfinded_t, but
>  since the admin _must_ add those files to /etc/postfix/main.cf (and
>  should allow only harmless files) I guess that this is ok.
>  
>  any objections or shall I try to write a patch for the policy?
>  
>  
>  ------------------------------------------------------------------------
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
What was the AVC you
were seeing that caused you to make this change?

[Christoph Höger]

Hi Dan,

I got something like:

type=SYSCALL msg=audit(1248337552.277:51): arch=40000003 syscall=5
success=yes exit=9 a0=2590dd8 a1=8000 a2=0 a3=0 items=0 ppid=3929
pid=3934 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=1 comm="smtp" exe="/usr/libexec/postfix/smtp"
subj=unconfined_u:system_r:postfix_smtp_t:s0 key=(null)
type=AVC msg=audit(1248337552.277:52): avc:  denied  { lock } for
pid=3934 comm="smtp" path="/home/choeger/cert/sasl_passwd.db"
dev=dm-1
ino=2976113 scontext=unconfined_u:system_r:postfix_smtp_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

(that's just a simple example)

Basically postfix_smtp_t and user_home_t do not play nice - which is not
a big surprise since that is what confinement is all about, but I wish
there would be a way to handle that use case.

[Daniel J Walsh]

On 07/23/2009 06:00 PM, Christoph Höger wrote:
>  Hi Dan,
>  
>  I got something like:
>  
>  type=SYSCALL msg=audit(1248337552.277:51): arch=40000003 syscall=5
>  success=yes exit=9 a0=2590dd8 a1=8000 a2=0 a3=0 items=0 ppid=3929
>  pid=3934 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>  fsgid=0 tty=(none) ses=1 comm="smtp" exe="/usr/libexec/postfix/smtp"
>  subj=unconfined_u:system_r:postfix_smtp_t:s0 key=(null)
>  type=AVC msg=audit(1248337552.277:52): avc:  denied  { lock } for
>  pid=3934 comm="smtp" path="/home/choeger/cert/sasl_passwd.db"
> dev=dm-1
>  ino=2976113 scontext=unconfined_u:system_r:postfix_smtp_t:s0
>  tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
>  
>  (that's just a simple example)
>  
>  Basically postfix_smtp_t and user_home_t do not play nice - which is not
>  a big surprise since that is what confinement is all about, but I wish
>  there would be a way to handle that use case.
>  
>  
>  ------------------------------------------------------------------------
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
THe best thing for
something like this is to set the labeling. If you want to have certificates in your
homedir, you need to set the labeling to something like cert_t.

# semanage fcontext -a -t cert_t '/home/choeger/cert(/.*)?'
# restorecon -R -v /home/choeger/cert

Should fix.