Issue on a new system

[mark]

We've just built a new machine, running CentOS 6.4. I built, then my
manager pulled stuff off the machine that it's replacing, installing as
necessary. I'm seeing a ton of complaints of "SELinux is preventing
/usr/libexec/dovecot/imap from search access on the directory indexes.".
Now, ps -Z | grep dove shows that dovecot's running as
unconfined_u:system_r:dovecot_t:s0, while a typical index it's trying to
read shows ll -Z as system_u:object_r:dovecot_t. As a side note, it's
owned by user, with group of nobody.

I see the same file on the old server as being system_u:object_r:var_spool_t.

Why would selinux be complaining? Is what was on the old system the
correct context?

      mark

[Miroslav Grepl]

On 04/22/2013 09:45 PM, m.roth(a)5-cent.us wrote:
>  We've just built a new machine, running CentOS 6.4. I built, then
> my
>  manager pulled stuff off the machine that it's replacing, installing as
>  necessary. I'm seeing a ton of complaints of "SELinux is preventing
>  /usr/libexec/dovecot/imap from search access on the directory indexes.".
>  Now, ps -Z | grep dove shows that dovecot's running as
>  unconfined_u:system_r:dovecot_t:s0, while a typical index it's trying to
>  read shows ll -Z as system_u:object_r:dovecot_t. As a side note, it's
>  owned by user, with group of nobody.
>
>  I see the same file on the old server as being system_u:object_r:var_spool_t.
>
>  Why would selinux be complaining? Is what was on the old system the
>  correct context?
>
>         mark
>
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
Could you attach AVC mgs?
Probably missing SELinux policy/contexts.

Regards,
Mirek

[mark]

m.roth(a)5-cent.us wrote:
>  We've just built a new machine, running CentOS 6.4. I built, then
> my
>  manager pulled stuff off the machine that it's replacing, installing as
>  necessary. I'm seeing a ton of complaints of "SELinux is preventing
>  /usr/libexec/dovecot/imap from search access on the directory indexes.".
>  Now, ps -Z | grep dove shows that dovecot's running as
>  unconfined_u:system_r:dovecot_t:s0, while a typical index it's trying to
>  read shows ll -Z as system_u:object_r:dovecot_t. As a side note, it's
>  owned by user, with group of nobody.
>
>  I see the same file on the old server as being
>  system_u:object_r:var_spool_t.
>
>  Why would selinux be complaining? Is what was on the old system the
>  correct context?
>  
This is very frustrating. My manager rebooted this morning, so now I'm not
sure about which avc I wrote about yesterday. However, I see various
things:
  1. Last night, dovecot was throwing AVCs... and I was looking at it
mentioning
        one user's email spool... but when I ran the sealert, it spoke of a
        *different* user's spool.

     Looking at a few of the AVCs, as Miroslav requested, *some* of this
may have changed, even without a relabel on the reboot, since I see
it complaining that something had been unlabled, where if I look at
it now with ll -Z, I see it as dovecot_t.

  2. Sendmail is complaining, among other things, that it can't write to
       /etc/sendmail/statistics. ll -Z shows
      -rw-r--r--. root root unconfined_u:object_r:etc_t:s0   statistics
      Meanwhile, I try to look at /usr/sbin/sendmail (ARGH!):
lrwxrwxrwx. root root system_u:object_r:bin_t:s0   /usr/sbin/sendmail -> 
/etc/alternatives/mta
lrwxrwxrwx. root root system_u:object_r:etc_t:s0      
/etc/alternatives/mta -> /usr/sbin/sendmail.sendmail
-rwxr-sr-x. root smmsp system_u:object_r:sendmail_exec_t:s0
/usr/sbin/sendmail.sendmail
        Looking further in my log, I see it's also complaining about
sendmail trying to do things to
/var/run/milter-greylist/milter-greylist.sock. So, can someone
suggest what I need to do to make selinux shut up about sendmail?
Typical AVC:
type=AVC msg=audit(1366726917.008:87837): avc:  denied  { write } for 
pid=1401 comm="sendmail" name="statistics" dev=sda3 ino=44769294
scontext=system_u:system_r:sendmail_t:s0
tcontext=unconfined_u:object_r:etc_t:s0 tclass=file

       Is this telling me that, as I asked yesterday, I need to change the
user context to system_u from unconfined_u?


   3. This one makes *zero* sense to me: SELinux is preventing
/lib64/security/pam_krb5/pam_krb5_storetmp from execute access on the
file /lib64/security/pam_krb5/pam_krb5_storetmp. ll -Z
-rwxr-xr-x. root root system_u:object_r:bin_t:s0      
/lib64/security/pam_krb5/pam_krb5_storetmp*

   I won't even start to get into the perl complaints....

       mark

[Miroslav Grepl]

On 04/23/2013 04:37 PM, m.roth(a)5-cent.us wrote:
>  m.roth(a)5-cent.us wrote:
> > We've just built a new machine, running CentOS 6.4. I built, then my
> > manager pulled stuff off the machine that it's replacing, installing as
> > necessary. I'm seeing a ton of complaints of "SELinux is preventing
> > /usr/libexec/dovecot/imap from search access on the directory indexes.".
> > Now, ps -Z | grep dove shows that dovecot's running as
> > unconfined_u:system_r:dovecot_t:s0, while a typical index it's trying to
> > read shows ll -Z as system_u:object_r:dovecot_t. As a side note, it's
> > owned by user, with group of nobody.
> >
> > I see the same file on the old server as being
> > system_u:object_r:var_spool_t.
> >
> > Why would selinux be complaining? Is what was on the old system the
> > correct context?
> >
>  This is very frustrating. My manager rebooted this morning, so now I'm not
>  sure about which avc I wrote about yesterday. However, I see various
>  things:
>     1. Last night, dovecot was throwing AVCs... and I was looking at it
>  mentioning
>           one user's email spool... but when I ran the sealert, it spoke of a
>           *different* user's spool.
>
>        Looking at a few of the AVCs, as Miroslav requested, *some* of this
>  may have changed, even without a relabel on the reboot, since I see
>  it complaining that something had been unlabled, where if I look at
>  it now with ll -Z, I see it as dovecot_t.
>
>     2. Sendmail is complaining, among other things, that it can't write to
>          /etc/sendmail/statistics. ll -Z shows
>         -rw-r--r--. root root unconfined_u:object_r:etc_t:s0   statistics
>         Meanwhile, I try to look at /usr/sbin/sendmail (ARGH!):
>  lrwxrwxrwx. root root system_u:object_r:bin_t:s0   /usr/sbin/sendmail ->
>  /etc/alternatives/mta
>  lrwxrwxrwx. root root system_u:object_r:etc_t:s0
>  /etc/alternatives/mta -> /usr/sbin/sendmail.sendmail
>  -rwxr-sr-x. root smmsp system_u:object_r:sendmail_exec_t:s0
>  /usr/sbin/sendmail.sendmail
>           Looking further in my log, I see it's also complaining about
>  sendmail trying to do things to
>  /var/run/milter-greylist/milter-greylist.sock. So, can someone
>  suggest what I need to do to make selinux shut up about sendmail?
>  Typical AVC:
>  type=AVC msg=audit(1366726917.008:87837): avc:  denied  { write } for
>  pid=1401 comm="sendmail" name="statistics" dev=sda3 ino=44769294
>  scontext=system_u:system_r:sendmail_t:s0
>  tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
>
>          Is this telling me that, as I asked yesterday, I need to change the
>  user context to system_u from unconfined_u?
>
>
>      3. This one makes *zero* sense to me: SELinux is preventing
>  /lib64/security/pam_krb5/pam_krb5_storetmp from execute access on the
>  file /lib64/security/pam_krb5/pam_krb5_storetmp. ll -Z
>  -rwxr-xr-x. root root system_u:object_r:bin_t:s0
>  /lib64/security/pam_krb5/pam_krb5_storetmp*
>
>      I won't even start to get into the perl complaints....
>
>          mark
>
>
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
Ok, hard to say without
AVC msgs. But for the first issue

milter_stream_connect_all(sendmail_t)

Then the problem is with

/etc/sendmail/statistics

which is supposed to be written in /etc directory. What does

# rpm -qf /etc/sendmail/statistics

# chcon -t etc_aliases_t /etc/sendmail/statistics

should fix it for now.

And last one would need

corecmd_exec_bin() for a source type from AVC msg which we don't have.

Regards,
Miroslav

[Zdenek Pytela]

Miroslav Grepl pise:
>  Ok, hard to say without AVC msgs. But for the first issue
>  
>  milter_stream_connect_all(sendmail_t)
>  
>  Then the problem is with
>  
>  /etc/sendmail/statistics
>  
>  which is supposed to be written in /etc directory. What does
>  
>  # rpm -qf /etc/sendmail/statistics
>  
>  # chcon -t etc_aliases_t /etc/sendmail/statistics
>  
>  should fix it for now. 
	Sendmail statistics file now usually resides in
/var/log/mail and is
with sendmail_log_t label,

-rw-------. root root system_u:object_r:sendmail_log_t:s0 /var/log/mail/statistics

This is in current RHEL and Fedora (it was already in Fedora 13); but
I don't know centos.

-- 

--Zdenek Pytela, <pytela(a)phil.muni.cz&gt;

[mark]

Zdenek Pytela wrote:
>  Miroslav Grepl pise:
> > Ok, hard to say without AVC msgs. But for the first issue
> >
> > milter_stream_connect_all(sendmail_t)
> >
> > Then the problem is with
> >
> > /etc/sendmail/statistics
> >
> > which is supposed to be written in /etc directory. What does
> >
> > # rpm -qf /etc/sendmail/statistics
> >
> > # chcon -t etc_aliases_t /etc/sendmail/statistics
> >
> > should fix it for now.
>  	Sendmail statistics file now usually resides in /var/log/mail and is
>  with sendmail_log_t label,
>
>  -rw-------. root root system_u:object_r:sendmail_log_t:s0
>  /var/log/mail/statistics
>
>  This is in current RHEL and Fedora (it was already in Fedora 13); but
>  I don't know centos.
>  
CentOS is == RHEL - it's rebuilt from source, minus proprietary stuff.

I just looked, and see it there, but it's got a date of 11 Nov 2010, with
nothing written there. This machine was newly built, so I'd expect it to
work correctly.

        mark