Hello All,
I have just upgraded (clean install) from F13 to F15 and installed spamassassin via yum.
At the same time I also installed the plugins Pyzor, Razor and iXhash.
In Permissive mode something in those triggers a strange AVC:
SELinux is preventing /bin/systemd-tty-ask-password-agent from read access on the fifo_file 136:0.
Here is the detail:
Raw Audit Messages type=AVC msg=audit(1307797576.537:29628): avc: denied { read } for pid=10471 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=282609 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
type=AVC msg=audit(1307797576.537:29628): avc: denied { open } for pid=10471 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=282609 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1307797576.537:29628): arch=i386 syscall=open success=yes exit=ESRCH a0=8ca9080 a1=88900 a2=0 a3=bf8fba54 items=0 ppid=10470 pid=10471 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm=systemd-tty-ask exe=/bin/systemd-tty-ask-password-agent subj=unconfined_u:system_r:systemd_passwd_agent_t:s0 key=(null)
Hash: systemd-tty-ask,systemd_passwd_agent_t,init_var_run_t,fifo_file,read
audit2allow
#============= systemd_passwd_agent_t ============== allow systemd_passwd_agent_t init_var_run_t:fifo_file { read open };
audit2allow -R
#============= systemd_passwd_agent_t ============== allow systemd_passwd_agent_t init_var_run_t:fifo_file { read open };
The other slightly odd thing is that when I place the system back into Enforcing mode I get no AVCs, but some of the Spamassassin checks (Especially iXhash I think) don't seem to be run, but give no errors.
Anyway, the above AVC looked strange and I didn't want to create a local policy module for it until I had checked with the chaps here...
Thanks in advance for any advice or suggestions...
Mark
On Sat, 2011-06-11 at 14:40 +0100, Arthur Dent wrote:
The other slightly odd thing is that when I place the system back into Enforcing mode I get no AVCs, but some of the Spamassassin checks (Especially iXhash I think) don't seem to be run, but give no errors.
Try to reproduce it after you ran : semodule -DB
semodule -DB loads the policy with any rules to silently deny access removed.
Then see for AVC denials again.
After checking do : semodule -B to load the policy with the rules to silently deny access re-inserted
Anyway, the above AVC looked strange and I didn't want to create a local policy module for it until I had checked with the chaps here...
This does not look particularly strange. The pipe is probably created by systemd.
On Sat, 2011-06-11 at 15:47 +0200, Dominick Grift wrote:
On Sat, 2011-06-11 at 14:40 +0100, Arthur Dent wrote:
The other slightly odd thing is that when I place the system back into Enforcing mode I get no AVCs, but some of the Spamassassin checks (Especially iXhash I think) don't seem to be run, but give no errors.
Try to reproduce it after you ran : semodule -DB
semodule -DB loads the policy with any rules to silently deny access removed.
Then see for AVC denials again.
After checking do : semodule -B to load the policy with the rules to silently deny access re-inserted
OK I'll try that..
Anyway, the above AVC looked strange and I didn't want to create a local policy module for it until I had checked with the chaps here...
This does not look particularly strange. The pipe is probably created by systemd.
So, should I create a policy module to allow it?
I guess the "ask-password" bit of "SELinux is preventing /bin/systemd-tty-ask-password-agent from read access on the fifo_file 136:0." worried me a bit...
On Sat, 2011-06-11 at 14:55 +0100, Arthur Dent wrote:
Anyway, the above AVC looked strange and I didn't want to create a local policy module for it until I had checked with the chaps here...
This does not look particularly strange. The pipe is probably created by systemd.
So, should I create a policy module to allow it?
Did you notice any loss of functionality? Anyways i do not see a problem with allowing it.
On 06/11/2011 02:57 PM, Dominick Grift wrote:
On Sat, 2011-06-11 at 14:55 +0100, Arthur Dent wrote:
Anyway, the above AVC looked strange and I didn't want to create a local policy module for it until I had checked with the chaps here...
This does not look particularly strange. The pipe is probably created by systemd.
So, should I create a policy module to allow it?
Did you notice any loss of functionality? Anyways i do not see a problem with allowing it.
I'm getting this when I restart opendkim on F-15:
type=AVC msg=audit(1316699607.377:150425): avc: denied { read } for pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=209876 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
type=AVC msg=audit(1316699607.377:150425): avc: denied { open } for pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=209876 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1316699607.377:150425): arch=c000003e syscall=2 success=yes exit=3 a0=14c60a0 a1=80900 a2=fffffffffffffed0 a3=7ffffdee5c80 items=1 ppid=4150 pid=4151 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=9220 comm="systemd-tty-ask" exe="/bin/systemd-tty-ask-password-agent" subj=unconfined_u:system_r:systemd_passwd_agent_t:s0 key=(null)
type=CWD msg=audit(1316699607.377:150425): cwd="/"
type=PATH msg=audit(1316699607.377:150425): item=0 name="/run/systemd/ask-password-block/136:0" inode=209876 dev=00:12 mode=010600 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:init_var_run_t:s0
I don't know what's happening here and it doesn't appear to affect the operation of opendkim, so I'm tempted to dontaudit it rather than allow it. But what is it actually trying to do?
Paul.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/22/2011 09:58 AM, Paul Howarth wrote:
On 06/11/2011 02:57 PM, Dominick Grift wrote:
On Sat, 2011-06-11 at 14:55 +0100, Arthur Dent wrote:
Anyway, the above AVC looked strange and I didn't want to create a local policy module for it until I had checked with the chaps here...
This does not look particularly strange. The pipe is probably created by systemd.
So, should I create a policy module to allow it?
Did you notice any loss of functionality? Anyways i do not see a problem with allowing it.
I'm getting this when I restart opendkim on F-15:
type=AVC msg=audit(1316699607.377:150425): avc: denied { read } for pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=209876 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
type=AVC msg=audit(1316699607.377:150425): avc: denied { open } for pid=4151 comm="systemd-tty-ask" name="136:0" dev=tmpfs ino=209876 scontext=unconfined_u:system_r:systemd_passwd_agent_t:s0 tcontext=unconfined_u:object_r:init_var_run_t:s0 tclass=fifo_file
type=SYSCALL msg=audit(1316699607.377:150425): arch=c000003e syscall=2 success=yes exit=3 a0=14c60a0 a1=80900 a2=fffffffffffffed0 a3=7ffffdee5c80 items=1 ppid=4150 pid=4151 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=9220 comm="systemd-tty-ask" exe="/bin/systemd-tty-ask-password-agent" subj=unconfined_u:system_r:systemd_passwd_agent_t:s0 key=(null)
type=CWD msg=audit(1316699607.377:150425): cwd="/"
type=PATH msg=audit(1316699607.377:150425): item=0 name="/run/systemd/ask-password-block/136:0" inode=209876 dev=00:12 mode=010600 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:init_var_run_t:s0
I don't know what's happening here and it doesn't appear to affect the operation of opendkim, so I'm tempted to dontaudit it rather than allow it. But what is it actually trying to do?
Paul. -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
This is allowed in F16/Rawhide policy. Looks like systemd functionality is being back ported into F15 and selinux-policy has to adapt.
selinux@lists.fedoraproject.org