FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 07-30-2008, 02:19 AM
Kristen Reitz
 
Default qmail labeling

List

I have had some trouble with qmail and SELinux. Following my
installation of qmail and running restorecon on the /var/qmail
directory tree I ran into AVC denial messages upon reboots.


When my server boots the smart daemon is trying to send mail stating
that I have a drive which is failing. (true, it's the one that caused
me to have CentOS 5.2 on a new drive). The smartd error messages follow:


Jul 24 14:31:39 host smartd[2598]: Monitoring 2 ATA and 0 SCSI devices
Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, FAILED SMART
self-check. BACK UP DATA NOW!

Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ...
Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced
unexpected output (32 bytes) to STDOUT/STDERR: qmail-inject: fatal:
read error

Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful
Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, 1522 Currently
unreadable (pending) sectors

Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ...
Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced
unexpected output (32 bytes) to STDOUT/STDERR: qmail-inject: fatal:
read error

Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful
Jul 24 14:31:39 host smartd[2606]: smartd has fork()ed into
background mode. New PID=2606.


Below is the reason for the fatal read error which is listed above as
being successful, but isn't. (AVC message not specific to the above
smartd error, it's just one of many related to the smartd error)


type=AVC msg=audit(1215375080.575:15): avc: denied { read } for
pid=2585 comm="qmail-inject" name="me" dev=dm-4 ino=3170476
scontext=system_u:system_r:system_mail_t:s0
tcontext=user_ubject_r:var_t:s0 tclass=file
type=SYSCALL msg=audit(1215375080.575:15): arch=40000003 syscall=5
success=no exit=-13 a0=804e45b a1=800 a2=0 a3=bfe68128 items=0
ppid=2584 pid=2585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qmail-inject"
exe="/var/qmail/bin/qmail-inject"
subj=system_u:system_r:system_mail_t:s0 key=(null)


The "me" file is in the /var/qmail/control/ directory, a directory
which hasn't any content labeling when I view a recent strict policy
file.


/var/qmail/bin(/.*)? system_ubject_r:bin_t:s0
/var/qmail/supervise(/.*)? system_ubject_r:svc_svc_t:s0
/var/qmail/supervise/.*/run --
system_ubject_r:svc_run_exec_t:s0
/var/qmail/supervise/.*/log/run --
system_ubject_r:svc_run_exec_t:s0

/var/qmail/rc -- system_ubject_r:bin_t:s0
/var/qmail/bin -d system_ubject_r:bin_t:s0
/var/qmail/bin/sendmail -- system_ubject_r:sendmail_exec_t:s0

The problem is when the system boots, the smartd finds my bad drive
and tries to email me about it. No emails arrive and I find rather
messages in my audit log. I ran audit2why to study this, then
audit2allow to create te rules. Below are the rules created which I
have implemented.


allow system_mail_t var_t:dir { write remove_name add_name };
allow system_mail_t var_t:fifo_file write;
allow system_mail_t var_t:file { write getattr link read create
unlink };


I now received email ( 2 messages total ) from the smartd following a
reboot. The question I have is this. Should I even be making allow
rules at all? Should not the policy file have the right labeling for
a qmail install? And since it appears to me it does not, should I be
making a policy file which I can then use restorecon to adjust my
system labeling with? Or are type enforcement rules truly the way to
go? I must admit I am new to SELinux and it's management so this is
all about learning. I am not seeking a 'fix' so much but rather an
understanding leading to a proper fix. I have read that relabeling
has security risk and should be avoided entirely. Perhaps that's
another subject all together?


Kristen





--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 07-30-2008, 03:41 PM
Daniel J Walsh
 
Default qmail labeling

Kristen Reitz wrote:
> List
>
> I have had some trouble with qmail and SELinux. Following my
> installation of qmail and running restorecon on the /var/qmail directory
> tree I ran into AVC denial messages upon reboots.
>
> When my server boots the smart daemon is trying to send mail stating
> that I have a drive which is failing. (true, it's the one that caused me
> to have CentOS 5.2 on a new drive). The smartd error messages follow:
>
> Jul 24 14:31:39 host smartd[2598]: Monitoring 2 ATA and 0 SCSI devices
> Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, FAILED SMART
> self-check. BACK UP DATA NOW!
> Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ...
> Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced
> unexpected output (32 bytes) to STDOUT/STDERR: qmail-inject: fatal:
> read error
> Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful
> Jul 24 14:31:39 host smartd[2598]: Device: /dev/hdb, 1522 Currently
> unreadable (pending) sectors
> Jul 24 14:31:39 host smartd[2598]: Sending warning via mail to root ...
> Jul 24 14:31:39 host smartd[2598]: Warning via mail to root produced
> unexpected output (32 bytes) to STDOUT/STDERR: qmail-inject: fatal:
> read error
> Jul 24 14:31:39 host smartd[2598]: Warning via mail to root: successful
> Jul 24 14:31:39 host smartd[2606]: smartd has fork()ed into background
> mode. New PID=2606.
>
> Below is the reason for the fatal read error which is listed above as
> being successful, but isn't. (AVC message not specific to the above
> smartd error, it's just one of many related to the smartd error)
>
> type=AVC msg=audit(1215375080.575:15): avc: denied { read } for
> pid=2585 comm="qmail-inject" name="me" dev=dm-4 ino=3170476
> scontext=system_u:system_r:system_mail_t:s0
> tcontext=user_ubject_r:var_t:s0 tclass=file
> type=SYSCALL msg=audit(1215375080.575:15): arch=40000003 syscall=5
> success=no exit=-13 a0=804e45b a1=800 a2=0 a3=bfe68128 items=0 ppid=2584
> pid=2585 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="qmail-inject"
> exe="/var/qmail/bin/qmail-inject"
> subj=system_u:system_r:system_mail_t:s0 key=(null)
>
> The "me" file is in the /var/qmail/control/ directory, a directory which
> hasn't any content labeling when I view a recent strict policy file.
>
> /var/qmail/bin(/.*)? system_ubject_r:bin_t:s0
> /var/qmail/supervise(/.*)? system_ubject_r:svc_svc_t:s0
> /var/qmail/supervise/.*/run -- system_ubject_r:svc_run_exec_t:s0
> /var/qmail/supervise/.*/log/run -- system_ubject_r:svc_run_exec_t:s0
> /var/qmail/rc -- system_ubject_r:bin_t:s0
> /var/qmail/bin -d system_ubject_r:bin_t:s0
> /var/qmail/bin/sendmail -- system_ubject_r:sendmail_exec_t:s0
>
> The problem is when the system boots, the smartd finds my bad drive and
> tries to email me about it. No emails arrive and I find rather messages
> in my audit log. I ran audit2why to study this, then audit2allow to
> create te rules. Below are the rules created which I have implemented.
>
> allow system_mail_t var_t:dir { write remove_name add_name };
> allow system_mail_t var_t:fifo_file write;
> allow system_mail_t var_t:file { write getattr link read create unlink };
>
> I now received email ( 2 messages total ) from the smartd following a
> reboot. The question I have is this. Should I even be making allow rules
> at all? Should not the policy file have the right labeling for a qmail
> install? And since it appears to me it does not, should I be making a
> policy file which I can then use restorecon to adjust my system labeling
> with? Or are type enforcement rules truly the way to go? I must admit I
> am new to SELinux and it's management so this is all about learning. I
> am not seeking a 'fix' so much but rather an understanding leading to a
> proper fix. I have read that relabeling has security risk and should be
> avoided entirely. Perhaps that's another subject all together?
>
> Kristen
>
>
>
>
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list


Could you try to label the directory mail_spool_t


chcon -R -t mail_spool_t /var/qmail

If that fixes the problem, you could execute this command to make it
survive a relabel

semanage fcontext -a -t mail_spool_t /var/qmail(/.*)?

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 

Thread Tools




All times are GMT. The time now is 04:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org