On Thu, May 06, 2010 at 08:35:25PM -0700, David Highley wrote:
> Did the usual dance after selinux policy seemed to get wiped out. Does
> not appear to be working. I also did an semodule -r mysshdfilter just to
> make sure there was not some thing fouled up.
>
> grep sshdfilter /var/log/audit/audit.log | tail -2 | audit2allow -M
> mysshdfilter
>
> semodule -i mysshdfilter.pp
>
>
> type=SYSCALL msg=audit(1273152205.754:30341): arch=c000003e syscall=2
> success=no exit=-13 a0=1f16088 a1=241 a2=1b6 a3=7f26f5e60920 items=0
> ppid=24925 pid=24926 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=(none) ses=731 comm="sshdfilter" exe="/usr/bin/perl"
> subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
> type=AVC msg=audit(1273152205.754:30341): avc: denied { write } for
> pid=24926 comm="sshdfilter" name="sshdfilter.pid.SSHD" dev=dm-0 ino=539
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:var_run_t:s0 tclass=file
Looks like this app may need policy. I could not find a sshdfilter package in the regular fedora repositories though.
The fact of the matter is that /var/run/sshdfilter.pid.SSHD somehow is mislabeled, and that sshd_t cannot access the mislabeled pid file.
In some cases using audit2allow to allow stuff is a bad idea. This is one such example.
The problem needs to be solved at it core. We need to figure out why and when the pid was mislabeled and make sure it instead gets a proper label.
> --
> selinux mailing list
> selinux@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
Attachment:
pgpHRdKPSYMwK.pgp
Description: PGP signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
