service not starting via systemd but no AVCs are generated

[Ed Greshko]

Hi,

On F19 the service fail2ban won't start via systemd with selinux in enforcing mode.

The error in the message log indicates....

fail2ban-client[2804]: ERROR Directory /var/run/fail2ban exists but not accessible for
writing

But, if you execute the command in the service file from the command line....

[root@f18x log]# /usr/bin/fail2ban-client -x start
2013-07-09 18:46:10,558 fail2ban.server : INFO   Starting Fail2ban v0.8.10
2013-07-09 18:46:10,559 fail2ban.server : INFO   Starting in daemon mode

It starts and you can see the files created in /var/run/fail2ban

[root@f18x fail2ban]# pwd
/var/run/fail2ban
[root@f18x fail2ban]# ls
fail2ban.pid  fail2ban.sock


And if you put selinux in permissive mode....

[root@f18x fail2ban]# pwd
/var/run/fail2ban
[root@f18x fail2ban]# ls
[root@f18x fail2ban]# setenforce 0
[root@f18x fail2ban]# systemctl start fail2ban
[root@f18x fail2ban]# ls
fail2ban.pid  fail2ban.sock

So it is running with selinux placed in permissive mode.....

But, no AVC are ever thrown to the audit log.

How to figure out what is the culprit?



-- 
The only thing worse than a poorly asked question is a cryptic answer.

[Tristan Santore]

On 09/07/13 13:29, Ed Greshko wrote:
>  Hi,
>  
>  On F19 the service fail2ban won't start via systemd with selinux in enforcing mode.
>  
>  The error in the message log indicates....
>  
>  fail2ban-client[2804]: ERROR Directory /var/run/fail2ban exists but not accessible for
> writing
>  
>  But, if you execute the command in the service file from the command line....
>  
>  [root@f18x log]# /usr/bin/fail2ban-client -x start
>  2013-07-09 18:46:10,558 fail2ban.server : INFO   Starting Fail2ban v0.8.10
>  2013-07-09 18:46:10,559 fail2ban.server : INFO   Starting in daemon mode
>  
>  It starts and you can see the files created in /var/run/fail2ban
>  
>  [root@f18x fail2ban]# pwd
>  /var/run/fail2ban
>  [root@f18x fail2ban]# ls
>  fail2ban.pid  fail2ban.sock
>  
>  
>  And if you put selinux in permissive mode....
>  
>  [root@f18x fail2ban]# pwd
>  /var/run/fail2ban
>  [root@f18x fail2ban]# ls
>  [root@f18x fail2ban]# setenforce 0
>  [root@f18x fail2ban]# systemctl start fail2ban
>  [root@f18x fail2ban]# ls
>  fail2ban.pid  fail2ban.sock
>  
>  So it is running with selinux placed in permissive mode.....
>  
>  But, no AVC are ever thrown to the audit log.
>  
>  How to figure out what is the culprit?
>  
>  
>   
Firstly, as I do not have a F19 handy at the moment, did you try
restorecon ? Secondly you might have to disable don't audit using
semodule -DB to get audit messages.
Then you should see some denials, if fail2ban has a don't audit option
in the policy.

Regards,
Tristan

-- 

Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[Ed Greshko]

On 07/09/13 20:42, Tristan Santore wrote:
>  On 09/07/13 13:29, Ed Greshko wrote:
> > Hi,
> >
> > On F19 the service fail2ban won't start via systemd with selinux in enforcing
> mode.
> >
> > The error in the message log indicates....
> >
> > fail2ban-client[2804]: ERROR Directory /var/run/fail2ban exists but not accessible
> for writing
> >
> > But, if you execute the command in the service file from the command line....
> >
> > [root@f18x log]# /usr/bin/fail2ban-client -x start
> > 2013-07-09 18:46:10,558 fail2ban.server : INFO   Starting Fail2ban v0.8.10
> > 2013-07-09 18:46:10,559 fail2ban.server : INFO   Starting in daemon mode
> >
> > It starts and you can see the files created in /var/run/fail2ban
> >
> > [root@f18x fail2ban]# pwd
> > /var/run/fail2ban
> > [root@f18x fail2ban]# ls
> > fail2ban.pid  fail2ban.sock
> >
> >
> > And if you put selinux in permissive mode....
> >
> > [root@f18x fail2ban]# pwd
> > /var/run/fail2ban
> > [root@f18x fail2ban]# ls
> > [root@f18x fail2ban]# setenforce 0
> > [root@f18x fail2ban]# systemctl start fail2ban
> > [root@f18x fail2ban]# ls
> > fail2ban.pid  fail2ban.sock
> >
> > So it is running with selinux placed in permissive mode.....
> >
> > But, no AVC are ever thrown to the audit log.
> >
> > How to figure out what is the culprit?
> >
> >
> >
>  Firstly, as I do not have a F19 handy at the moment, did you try
>  restorecon ? Secondly you might have to disable don't audit using
>  semodule -DB to get audit messages.
>  Then you should see some denials, if fail2ban has a don't audit option
>  in the policy. 
I had forgotten all about the "semodule -DB" procedure ....

There are a "few" of them now generated....

type=AVC msg=audit(1373375036.941:752): avc:  denied  { search } for  pid=3806
comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
tclass=dir
type=AVC msg=audit(1373375036.946:753): avc:  denied  { rlimitinh } for  pid=3808
comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1373375036.946:753): avc:  denied  { siginh } for  pid=3808
comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1373375036.946:753): avc:  denied  { noatsecure } for  pid=3808
comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1373375037.385:754): avc:  denied  { write } for  pid=3808
comm="setroubleshootd" name=".dbenv.lock" dev="dm-1"
ino=1048913 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file
type=AVC msg=audit(1373375037.454:755): avc:  denied  { write } for  pid=3806
comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
scontext=system_u:system_r:fail2ban_client_t:s0
tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
type=AVC msg=audit(1373375037.599:759): avc:  denied  { search } for  pid=3814
comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
tclass=dir
type=AVC msg=audit(1373375038.114:760): avc:  denied  { write } for  pid=3814
comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
scontext=system_u:system_r:fail2ban_client_t:s0
tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
type=AVC msg=audit(1373375038.257:764): avc:  denied  { search } for  pid=3816
comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
tclass=dir
type=AVC msg=audit(1373375038.872:765): avc:  denied  { write } for  pid=3816
comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
scontext=system_u:system_r:fail2ban_client_t:s0
tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
type=AVC msg=audit(1373375039.013:769): avc:  denied  { search } for  pid=3818
comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
tclass=dir
type=AVC msg=audit(1373375039.578:770): avc:  denied  { write } for  pid=3818
comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
scontext=system_u:system_r:fail2ban_client_t:s0
tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
type=AVC msg=audit(1373375039.716:774): avc:  denied  { search } for  pid=3820
comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
tclass=dir
type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for  pid=3820
comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
scontext=system_u:system_r:fail2ban_client_t:s0
tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
-- 
The only thing worse than a poorly asked question is a cryptic answer.

[Ed Greshko]

On 07/09/13 21:06, Ed Greshko wrote:


Sorry to be responding to myself....but....

It seems this AVC is the relevant one since /run is on tmpfs.
>  type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for  pid=3820
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir 
Not being fluent in selinux....  Would this be a bug in the fail2ban policy module.... 
Or, something else?

-- 
The only thing worse than a poorly asked question is a cryptic answer.

[Tristan Santore]

On 09/07/13 14:06, Ed Greshko wrote:
>  type=AVC msg=audit(1373375036.941:752): avc:  denied  { search } for 
> pid=3806 comm="fail2ban-client" name="root" dev="dm-1"
> ino=1310721 scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
>  type=AVC msg=audit(1373375036.946:753): avc:  denied  { rlimitinh } for  pid=3808
> comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
>  type=AVC msg=audit(1373375036.946:753): avc:  denied  { siginh } for  pid=3808
> comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
>  type=AVC msg=audit(1373375036.946:753): avc:  denied  { noatsecure } for  pid=3808
> comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
>  type=AVC msg=audit(1373375037.385:754): avc:  denied  { write } for  pid=3808
> comm="setroubleshootd" name=".dbenv.lock" dev="dm-1"
> ino=1048913 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file
>  type=AVC msg=audit(1373375037.454:755): avc:  denied  { write } for  pid=3806
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  type=AVC msg=audit(1373375037.599:759): avc:  denied  { search } for  pid=3814
> comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
> scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
> tclass=dir
>  type=AVC msg=audit(1373375038.114:760): avc:  denied  { write } for  pid=3814
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  type=AVC msg=audit(1373375038.257:764): avc:  denied  { search } for  pid=3816
> comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
> scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
> tclass=dir
>  type=AVC msg=audit(1373375038.872:765): avc:  denied  { write } for  pid=3816
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  type=AVC msg=audit(1373375039.013:769): avc:  denied  { search } for  pid=3818
> comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
> scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
> tclass=dir
>  type=AVC msg=audit(1373375039.578:770): avc:  denied  { write } for  pid=3818
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  type=AVC msg=audit(1373375039.716:774): avc:  denied  { search } for  pid=3820
> comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
> scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
> tclass=dir
>  type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for  pid=3820
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir 
That appears to be a
bug. It should allow:
allow fail2ban_client_t fail2ban_var_run_t:dir write;

Not so sure why it would want to access admin_home_t though.


Create a policy with that line in. And yes, it is a bug. Because
/var/run/fail2ban.*                                all files
system_u:object_r:fail2ban_var_run_t:s0 is labelled.
I haven't got fail2ban installed here, but it should allow it to create
the pid file and socket. You might find after that the access to the
socket also gets blocked. So fix the one issue, then check the audit log
again.

Make sure you please file a bug on bugzilla.redhat.com against the
selinux-policy package.

Regards,
Tristan

-- 

Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[Dominick Grift]

On Tue, 2013-07-09 at 20:29 +0800, Ed Greshko wrote:
>  Hi,
>  
>  On F19 the service fail2ban won't start via systemd with selinux in enforcing mode.
>  
>  The error in the message log indicates....
>  
>  fail2ban-client[2804]: ERROR Directory /var/run/fail2ban exists but not accessible for
> writing
>   
reproduce the issue without "dontaudit" rules:

semodule -DB
reproduce issue
see audit.log for avc denials
semodule -B


>  But, if you execute the command in the service file from the command
> line....
>  
>  [root@f18x log]# /usr/bin/fail2ban-client -x start
>  2013-07-09 18:46:10,558 fail2ban.server : INFO   Starting Fail2ban v0.8.10
>  2013-07-09 18:46:10,559 fail2ban.server : INFO   Starting in daemon mode
>  
>  It starts and you can see the files created in /var/run/fail2ban
>  
>  [root@f18x fail2ban]# pwd
>  /var/run/fail2ban
>  [root@f18x fail2ban]# ls
>  fail2ban.pid  fail2ban.sock
>  
>  
>  And if you put selinux in permissive mode....
>  
>  [root@f18x fail2ban]# pwd
>  /var/run/fail2ban
>  [root@f18x fail2ban]# ls
>  [root@f18x fail2ban]# setenforce 0
>  [root@f18x fail2ban]# systemctl start fail2ban
>  [root@f18x fail2ban]# ls
>  fail2ban.pid  fail2ban.sock
>  
>  So it is running with selinux placed in permissive mode.....
>  
>  But, no AVC are ever thrown to the audit log.
>  
>  How to figure out what is the culprit?
>  
>  
>

[Ed Greshko]

On 07/09/13 21:33, Tristan Santore wrote:
>  That appears to be a bug. It should allow:
>  allow fail2ban_client_t fail2ban_var_run_t:dir write;
>
>  Not so sure why it would want to access admin_home_t though.
>
>
>  Create a policy with that line in. And yes, it is a bug. Because
>  /var/run/fail2ban.*                                all files
>  system_u:object_r:fail2ban_var_run_t:s0 is labelled.
>  I haven't got fail2ban installed here, but it should allow it to create
>  the pid file and socket. You might find after that the access to the
>  socket also gets blocked. So fix the one issue, then check the audit log
>  again.
>
>  Make sure you please file a bug on bugzilla.redhat.com against the
>  selinux-policy package. 
OK, I went ahead and did the usual

grep fail2ban /var/log/audit/audit.log | audit2allow -M myfail2ban

and it now starts in enforcing mode.

I don't use fail2ban myself.  I was just helping someone else.

Now, to write the bugzilla.  

Thanks,
Ed

-- 
The only thing worse than a poorly asked question is a cryptic answer.

[Tristan Santore]

On 09/07/13 14:55, Ed Greshko wrote:
>  On 07/09/13 21:33, Tristan Santore wrote:
> > That appears to be a bug. It should allow:
> > allow fail2ban_client_t fail2ban_var_run_t:dir write;
> >
> > Not so sure why it would want to access admin_home_t though.
> >
> >
> > Create a policy with that line in. And yes, it is a bug. Because
> > /var/run/fail2ban.*                                all files
> > system_u:object_r:fail2ban_var_run_t:s0 is labelled.
> > I haven't got fail2ban installed here, but it should allow it to create
> > the pid file and socket. You might find after that the access to the
> > socket also gets blocked. So fix the one issue, then check the audit log
> > again.
> >
> > Make sure you please file a bug on bugzilla.redhat.com against the
> > selinux-policy package.
>  
>  OK, I went ahead and did the usual
>  
>  grep fail2ban /var/log/audit/audit.log | audit2allow -M myfail2ban
>  
>  and it now starts in enforcing mode.
>  
>  I don't use fail2ban myself.  I was just helping someone else.
>  
>  Now, to write the bugzilla.  
>  
>  Thanks,
>  Ed
>   
I am not sure the root home dir search should be allowed. Might be worth
throwing that one out and just trying the one line I gave you.

Anyway, glad it works.

Regards,
Tristan

-- 

Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[Ed Greshko]

On 07/09/13 22:02, Tristan Santore wrote:
>  On 09/07/13 14:55, Ed Greshko wrote:
> > On 07/09/13 21:33, Tristan Santore wrote:
> >> That appears to be a bug. It should allow:
> >> allow fail2ban_client_t fail2ban_var_run_t:dir write;
> >>
> >> Not so sure why it would want to access admin_home_t though.
> >>
> >>
> >> Create a policy with that line in. And yes, it is a bug. Because
> >> /var/run/fail2ban.*                                all files
> >> system_u:object_r:fail2ban_var_run_t:s0 is labelled.
> >> I haven't got fail2ban installed here, but it should allow it to create
> >> the pid file and socket. You might find after that the access to the
> >> socket also gets blocked. So fix the one issue, then check the audit log
> >> again.
> >>
> >> Make sure you please file a bug on bugzilla.redhat.com against the
> >> selinux-policy package.
> > OK, I went ahead and did the usual
> >
> > grep fail2ban /var/log/audit/audit.log | audit2allow -M myfail2ban
> >
> > and it now starts in enforcing mode.
> >
> > I don't use fail2ban myself.  I was just helping someone else.
> >
> > Now, to write the bugzilla.  
> >
> > Thanks,
> > Ed
> >
>  I am not sure the root home dir search should be allowed. Might be worth
>  throwing that one out and just trying the one line I gave you.
>
>  Anyway, glad it works. 
FYI....

There appears to be a bugzilla already open on this issue....

https://bugzilla.redhat.com/show_bug.cgi?id=975695

Thanks,
Ed

-- 
The only thing worse than a poorly asked question is a cryptic answer.

[Dominick Grift]

On Tue, 2013-07-09 at 14:33 +0100, Tristan Santore wrote:
>  On 09/07/13 14:06, Ed Greshko wrote:
>  > type=AVC msg=audit(1373375036.941:752): avc:  denied  { search } for  pid=3806
> comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
> scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
> tclass=dir
>  > type=AVC msg=audit(1373375036.946:753): avc:  denied  { rlimitinh } for  pid=3808
> comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
>  > type=AVC msg=audit(1373375036.946:753): avc:  denied  { siginh } for  pid=3808
> comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
>  > type=AVC msg=audit(1373375036.946:753): avc:  denied  { noatsecure } for  pid=3808
> comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
>  > type=AVC msg=audit(1373375037.385:754): avc:  denied  { write } for  pid=3808
> comm="setroubleshootd" name=".dbenv.lock" dev="dm-1"
> ino=1048913 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file
>  > type=AVC msg=audit(1373375037.454:755): avc:  denied  { write } for  pid=3806
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  > type=AVC msg=audit(1373375037.599:759): avc:  denied  { search } for  pid=3814
> comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
> scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
> tclass=dir
>  > type=AVC msg=audit(1373375038.114:760): avc:  denied  { write } for  pid=3814
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  > type=AVC msg=audit(1373375038.257:764): avc:  denied  { search } for  pid=3816
> comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
> scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
> tclass=dir
>  > type=AVC msg=audit(1373375038.872:765): avc:  denied  { write } for  pid=3816
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  > type=AVC msg=audit(1373375039.013:769): avc:  denied  { search } for  pid=3818
> comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
> scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
> tclass=dir
>  > type=AVC msg=audit(1373375039.578:770): avc:  denied  { write } for  pid=3818
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  > type=AVC msg=audit(1373375039.716:774): avc:  denied  { search } for  pid=3820
> comm="fail2ban-client" name="root" dev="dm-1" ino=1310721
> scontext=system_u:system_r:fail2ban_client_t:s0 tcontext=system_u:object_r:admin_home_t:s0
> tclass=dir
>  > type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for  pid=3820
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  That appears to be a bug. It should allow:
>  allow fail2ban_client_t fail2ban_var_run_t:dir write;
>  
>  Not so sure why it would want to access admin_home_t though. 
traverse the cwd
the command fail2ban-client was run from /root

[Dominick Grift]

On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
>  On 07/09/13 21:06, Ed Greshko wrote:
>  
>  
>  Sorry to be responding to myself....but....
>  
>  It seems this AVC is the relevant one since /run is on tmpfs.
>  >
>  > type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for  pid=3820
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  
>  Not being fluent in selinux....  Would this be a bug in the fail2ban policy module.... 
> Or, something else?
>   
yes a bug in the fail2ban policy module

either the fail2ban client checks to see if /run/fail2ban is writable or
it actually wants to create something in there ( but there is currently
no trace of the latter)

[Ed Greshko]

On 07/09/13 22:27, Dominick Grift wrote:
>  On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
> > On 07/09/13 21:06, Ed Greshko wrote:
> >
> >
> > Sorry to be responding to myself....but....
> >
> > It seems this AVC is the relevant one since /run is on tmpfs.
> >> type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for  pid=3820
> comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=28732
> scontext=system_u:system_r:fail2ban_client_t:s0
> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
> > Not being fluent in selinux....  Would this be a bug in the fail2ban policy
> module....  Or, something else?
> >
>  yes a bug in the fail2ban policy module
>
>  either the fail2ban client checks to see if /run/fail2ban is writable or
>  it actually wants to create something in there ( but there is currently
>  no trace of the latter)
>  
It seems a bugzilla already has been written....but against beta F19.

https://bugzilla.redhat.com/show_bug.cgi?id=975695

It does want to create a run.pid and a socket

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/09/2013 10:27 AM, Dominick Grift wrote:
>  On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
> > On 07/09/13 21:06, Ed Greshko wrote:
> > 
> > 
> > Sorry to be responding to myself....but....
> > 
> > It seems this AVC is the relevant one since /run is on tmpfs.
> >> 
> >> type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for
> >> pid=3820 comm="fail2ban-client" name="fail2ban"
> dev="tmpfs" ino=28732
> >> scontext=system_u:system_r:fail2ban_client_t:s0
> >> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
> > 
> > Not being fluent in selinux....  Would this be a bug in the fail2ban
> > policy module....  Or, something else?
> > 
>  
>  yes a bug in the fail2ban policy module
>  
>  either the fail2ban client checks to see if /run/fail2ban is writable or it
>  actually wants to create something in there ( but there is currently no
>  trace of the latter)
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
It seems that fail2ban-client is doing a check to see if it can write there
before using the socket.  Seems like a bogus check which we don't audited
before, but now seems to be causing problems.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHcKnQACgkQrlYvE4MpobMJwgCeIVcJqt4WPlR0ai0SVH+BZptt
> 23QAn0sDF6gF1GEjHmu9e2deoZnWoCuG
> =odl6
> -----END PGP SIGNATURE-----

[Dominick Grift]

On Tue, 2013-07-09 at 11:21 -0400, Daniel J Walsh wrote:
>  On 07/09/2013 10:27 AM, Dominick Grift wrote:
>  > On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
>  >> On 07/09/13 21:06, Ed Greshko wrote:
>  >> 
>  >> 
>  >> Sorry to be responding to myself....but....
>  >> 
>  >> It seems this AVC is the relevant one since /run is on tmpfs.
>  >>> 
>  >>> type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for
>  >>> pid=3820 comm="fail2ban-client" name="fail2ban"
> dev="tmpfs" ino=28732
>  >>> scontext=system_u:system_r:fail2ban_client_t:s0
>  >>> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  >> 
>  >> Not being fluent in selinux....  Would this be a bug in the fail2ban
>  >> policy module....  Or, something else?
>  >> 
>  > 
>  > yes a bug in the fail2ban policy module
>  > 
>  > either the fail2ban client checks to see if /run/fail2ban is writable or it
>  > actually wants to create something in there ( but there is currently no
>  > trace of the latter) 
I noticed that fedora uses the audit_access av perm wrong ( at least to
the best of my knowledge)

What fedora does:

dontaudit somedomain_t somefile_t:file audit_access;

How i believe it should be used:

dontaudit somedomain_t somefile_t:file write;
allow somedomain_t somefile_t:file audit_access;

Although, and i have not checked this, it sometimes seems that it does
not work either way. I still need to verify that. ( i might actually do
that now)

>  > 
>  > -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  > https://admin.fedoraproject.org/mailman/listinfo/selinux
>  > 
>  It seems that fail2ban-client is doing a check to see if it can write there
>  before using the socket.  Seems like a bogus check which we don't audited
>  before, but now seems to be causing problems.

[Dominick Grift]

On Tue, 2013-07-09 at 18:06 +0200, Dominick Grift wrote:
>  On Tue, 2013-07-09 at 11:21 -0400, Daniel J Walsh wrote:
>  > On 07/09/2013 10:27 AM, Dominick Grift wrote:
>  > > On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
>  > >> On 07/09/13 21:06, Ed Greshko wrote:
>  > >> 
>  > >> 
>  > >> Sorry to be responding to myself....but....
>  > >> 
>  > >> It seems this AVC is the relevant one since /run is on tmpfs.
>  > >>> 
>  > >>> type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for
>  > >>> pid=3820 comm="fail2ban-client" name="fail2ban"
> dev="tmpfs" ino=28732
>  > >>> scontext=system_u:system_r:fail2ban_client_t:s0
>  > >>> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  > >> 
>  > >> Not being fluent in selinux....  Would this be a bug in the fail2ban
>  > >> policy module....  Or, something else?
>  > >> 
>  > > 
>  > > yes a bug in the fail2ban policy module
>  > > 
>  > > either the fail2ban client checks to see if /run/fail2ban is writable or it
>  > > actually wants to create something in there ( but there is currently no
>  > > trace of the latter)
>  
>  I noticed that fedora uses the audit_access av perm wrong ( at least to
>  the best of my knowledge)
>  
>  What fedora does:
>  
>  dontaudit somedomain_t somefile_t:file audit_access;
>  
>  How i believe it should be used:
>  
>  dontaudit somedomain_t somefile_t:file write;
>  allow somedomain_t somefile_t:file audit_access;
>  
>  Although, and i have not checked this, it sometimes seems that it does
>  not work either way. I still need to verify that. ( i might actually do
>  that now) 
So either i am not understanding audit_access or it just doesnt work.

I just tried it and here is a situation where i think audit_access
should apply:

type=SYSCALL msg=audit(07/09/2013 18:14:07.930:663) : arch=x86_64
syscall=access success=no exit=-13(Permission denied) a0=0x2b040a5
a1=X_OK a2=0x6e69622f a3=0x387da86b20 items=0 ppid=1836 pid=2090
auid=myloginuser uid=myloginuser gid=myloginuser euid=myloginuser
suid=myloginuser fsuid=myloginuser egid=myloginuser sgid=myloginuser
fsgid=myloginuser ses=2 tty=(none) comm=gnome-shell
exe=/usr/bin/gnome-shell
subj=myloginuser_u:myloginuser_r:myloginuser_gshell_t:s0 key=(null)
type=AVC msg=audit(07/09/2013 18:14:07.930:663) : avc:  denied
{ execute } for  pid=2090 comm=gnome-shell name=logfactor5 dev="dm-2"
ino=10236053
scontext=myloginuser_u:myloginuser_r:myloginuser_gshell_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file

As you can se it checks access for X_OK, so a rule like:

allow myloginuser_gshell_t bin_t:file audit_access;

.. should make it succeed. But it doesnt

So i added another rule:

auditallow myloginuser_gshell_t bin_t:file audit_access;

.. to see if it actually hits that. But it doesnt.

So we end up with "success=no" and no proof that this audit_access av
permission was ever used.

push comes to show the access test fails, in resume: audit_access is
useless and broken, it doesnt work.

[Eric Paris]

On Tue, 2013-07-09 at 18:06 +0200, Dominick Grift wrote:
>  On Tue, 2013-07-09 at 11:21 -0400, Daniel J Walsh wrote:
>  > On 07/09/2013 10:27 AM, Dominick Grift wrote:
>  > > On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
>  > >> On 07/09/13 21:06, Ed Greshko wrote:
>  > >> 
>  > >> 
>  > >> Sorry to be responding to myself....but....
>  > >> 
>  > >> It seems this AVC is the relevant one since /run is on tmpfs.
>  > >>> 
>  > >>> type=AVC msg=audit(1373375040.246:775): avc:  denied  { write } for
>  > >>> pid=3820 comm="fail2ban-client" name="fail2ban"
> dev="tmpfs" ino=28732
>  > >>> scontext=system_u:system_r:fail2ban_client_t:s0
>  > >>> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  > >> 
>  > >> Not being fluent in selinux....  Would this be a bug in the fail2ban
>  > >> policy module....  Or, something else?
>  > >> 
>  > > 
>  > > yes a bug in the fail2ban policy module
>  > > 
>  > > either the fail2ban client checks to see if /run/fail2ban is writable or it
>  > > actually wants to create something in there ( but there is currently no
>  > > trace of the latter)
>  
>  I noticed that fedora uses the audit_access av perm wrong ( at least to
>  the best of my knowledge)
>  
>  What fedora does:
>  
>  dontaudit somedomain_t somefile_t:file audit_access;
>  
>  How i believe it should be used:
>  
>  dontaudit somedomain_t somefile_t:file write;
>  allow somedomain_t somefile_t:file audit_access;
>  
>  Although, and i have not checked this, it sometimes seems that it does
>  not work either way. I still need to verify that. ( i might actually do
>  that now) 
It is using it correctly.  audit_access is weird and special..

allow for the perm audit_access means nothing at all...

dontaudit somedomain_t somefile_t:file audit_access;

means we don't audit failures in the access(2) syscall, but we do audit
failures on open/read/write...

We added this because nautilus does access(2) checks on every file in
the world to decide how to display it on the screen.  We didn't want to
hide users actually trying to open the file for read/write, but did want
to hide all of the 'denials' from access(2)

Disabling dontaudit should make things show up even for access(2)....

[Dominick Grift]

On Tue, 2013-07-09 at 12:37 -0400, Eric Paris wrote:
>  On Tue, 2013-07-09 at 18:06 +0200, Dominick Grift wrote:
>  > On Tue, 2013-07-09 at 11:21 -0400, Daniel J Walsh wrote:
>  > > On 07/09/2013 10:27 AM, Dominick Grift wrote:
>  > > > On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
>  > > >> On 07/09/13 21:06, Ed Greshko wrote:
>  > > >> 
>  > > >> 
>  > > >> Sorry to be responding to myself....but....
>  > > >> 
>  > > >> It seems this AVC is the relevant one since /run is on tmpfs.
>  > > >>> 
>  > > >>> type=AVC msg=audit(1373375040.246:775): avc:  denied  { write }
> for
>  > > >>> pid=3820 comm="fail2ban-client"
> name="fail2ban" dev="tmpfs" ino=28732
>  > > >>> scontext=system_u:system_r:fail2ban_client_t:s0
>  > > >>> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  > > >> 
>  > > >> Not being fluent in selinux....  Would this be a bug in the fail2ban
>  > > >> policy module....  Or, something else?
>  > > >> 
>  > > > 
>  > > > yes a bug in the fail2ban policy module
>  > > > 
>  > > > either the fail2ban client checks to see if /run/fail2ban is writable or
> it
>  > > > actually wants to create something in there ( but there is currently no
>  > > > trace of the latter)
>  > 
>  > I noticed that fedora uses the audit_access av perm wrong ( at least to
>  > the best of my knowledge)
>  > 
>  > What fedora does:
>  > 
>  > dontaudit somedomain_t somefile_t:file audit_access;
>  > 
>  > How i believe it should be used:
>  > 
>  > dontaudit somedomain_t somefile_t:file write;
>  > allow somedomain_t somefile_t:file audit_access;
>  > 
>  > Although, and i have not checked this, it sometimes seems that it does
>  > not work either way. I still need to verify that. ( i might actually do
>  > that now)
>  
>  It is using it correctly.  audit_access is weird and special..
>  
>  allow for the perm audit_access means nothing at all...
>  
>  dontaudit somedomain_t somefile_t:file audit_access;
>  
>  means we don't audit failures in the access(2) syscall, but we do audit
>  failures on open/read/write...
>  
>  We added this because nautilus does access(2) checks on every file in
>  the world to decide how to display it on the screen.  We didn't want to
>  hide users actually trying to open the file for read/write, but did want
>  to hide all of the 'denials' from access(2)
>  
>  Disabling dontaudit should make things show up even for access(2)....
>   
ok that explains it thanks
strange though because i seem to remember that the commit message for
this feature suggested otherwise. nonetheless now its clear to me

[Dominick Grift]

On Tue, 2013-07-09 at 12:37 -0400, Eric Paris wrote:
>  On Tue, 2013-07-09 at 18:06 +0200, Dominick Grift wrote:
>  > On Tue, 2013-07-09 at 11:21 -0400, Daniel J Walsh wrote:
>  > > On 07/09/2013 10:27 AM, Dominick Grift wrote:
>  > > > On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
>  > > >> On 07/09/13 21:06, Ed Greshko wrote:
>  > > >> 
>  > > >> 
>  > > >> Sorry to be responding to myself....but....
>  > > >> 
>  > > >> It seems this AVC is the relevant one since /run is on tmpfs.
>  > > >>> 
>  > > >>> type=AVC msg=audit(1373375040.246:775): avc:  denied  { write }
> for
>  > > >>> pid=3820 comm="fail2ban-client"
> name="fail2ban" dev="tmpfs" ino=28732
>  > > >>> scontext=system_u:system_r:fail2ban_client_t:s0
>  > > >>> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  > > >> 
>  > > >> Not being fluent in selinux....  Would this be a bug in the fail2ban
>  > > >> policy module....  Or, something else?
>  > > >> 
>  > > > 
>  > > > yes a bug in the fail2ban policy module
>  > > > 
>  > > > either the fail2ban client checks to see if /run/fail2ban is writable or
> it
>  > > > actually wants to create something in there ( but there is currently no
>  > > > trace of the latter)
>  > 
>  > I noticed that fedora uses the audit_access av perm wrong ( at least to
>  > the best of my knowledge)
>  > 
>  > What fedora does:
>  > 
>  > dontaudit somedomain_t somefile_t:file audit_access;
>  > 
>  > How i believe it should be used:
>  > 
>  > dontaudit somedomain_t somefile_t:file write;
>  > allow somedomain_t somefile_t:file audit_access;
>  > 
>  > Although, and i have not checked this, it sometimes seems that it does
>  > not work either way. I still need to verify that. ( i might actually do
>  > that now)
>  
>  It is using it correctly.  audit_access is weird and special..
>  
>  allow for the perm audit_access means nothing at all...
>  
>  dontaudit somedomain_t somefile_t:file audit_access;
>  
>  means we don't audit failures in the access(2) syscall, but we do audit
>  failures on open/read/write...
>  
>  We added this because nautilus does access(2) checks on every file in
>  the world to decide how to display it on the screen.  We didn't want to
>  hide users actually trying to open the file for read/write, but did want
>  to hide all of the 'denials' from access(2)
>  
>  Disabling dontaudit should make things show up even for access(2).... 
So now that i know how to use it. it raises other questions.

Isnt silently denying access checks the world upside-down? If it should
not do access checks then should it not be fixed in the component rather
than silently hidden in policy.

If nautilus cannot perform access checks on files then it will put a big
fat lock and cross label on the icon representing the file.

I think apps generally do access checks for legitimate reasons and not
for their health.

So to me this is useless. I would rather have seen a new av perm for
access(2) checks if that would have been at all possible.

Now we have a av permission that is solely for dontaudit purposes. Sets
not such a good precedent.

[Eric Paris]

On Tue, 2013-07-09 at 19:35 +0200, Dominick Grift wrote:
>  On Tue, 2013-07-09 at 12:37 -0400, Eric Paris wrote:
>  > On Tue, 2013-07-09 at 18:06 +0200, Dominick Grift wrote:
>  > > On Tue, 2013-07-09 at 11:21 -0400, Daniel J Walsh wrote:
>  > > > On 07/09/2013 10:27 AM, Dominick Grift wrote:
>  > > > > On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
>  > > > >> On 07/09/13 21:06, Ed Greshko wrote:
>  > > > >> 
>  > > > >> 
>  > > > >> Sorry to be responding to myself....but....
>  > > > >> 
>  > > > >> It seems this AVC is the relevant one since /run is on tmpfs.
>  > > > >>> 
>  > > > >>> type=AVC msg=audit(1373375040.246:775): avc:  denied  { write
> } for
>  > > > >>> pid=3820 comm="fail2ban-client"
> name="fail2ban" dev="tmpfs" ino=28732
>  > > > >>> scontext=system_u:system_r:fail2ban_client_t:s0
>  > > > >>> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>  > > > >> 
>  > > > >> Not being fluent in selinux....  Would this be a bug in the
> fail2ban
>  > > > >> policy module....  Or, something else?
>  > > > >> 
>  > > > > 
>  > > > > yes a bug in the fail2ban policy module
>  > > > > 
>  > > > > either the fail2ban client checks to see if /run/fail2ban is writable
> or it
>  > > > > actually wants to create something in there ( but there is currently
> no
>  > > > > trace of the latter)
>  > > 
>  > > I noticed that fedora uses the audit_access av perm wrong ( at least to
>  > > the best of my knowledge)
>  > > 
>  > > What fedora does:
>  > > 
>  > > dontaudit somedomain_t somefile_t:file audit_access;
>  > > 
>  > > How i believe it should be used:
>  > > 
>  > > dontaudit somedomain_t somefile_t:file write;
>  > > allow somedomain_t somefile_t:file audit_access;
>  > > 
>  > > Although, and i have not checked this, it sometimes seems that it does
>  > > not work either way. I still need to verify that. ( i might actually do
>  > > that now)
>  > 
>  > It is using it correctly.  audit_access is weird and special..
>  > 
>  > allow for the perm audit_access means nothing at all...
>  > 
>  > dontaudit somedomain_t somefile_t:file audit_access;
>  > 
>  > means we don't audit failures in the access(2) syscall, but we do audit
>  > failures on open/read/write...
>  > 
>  > We added this because nautilus does access(2) checks on every file in
>  > the world to decide how to display it on the screen.  We didn't want to
>  > hide users actually trying to open the file for read/write, but did want
>  > to hide all of the 'denials' from access(2)
>  > 
>  > Disabling dontaudit should make things show up even for access(2)....
>  
>  So now that i know how to use it. it raises other questions. 
It is very very weird.  I agree.

>  Isnt silently denying access checks the world upside-down? If it
> should
>  not do access checks then should it not be fixed in the component rather
>  than silently hidden in policy. 
You can't 'fix' nautilis.  It needs to ask if it has read/write/execute
permission to do its job.  So I'm left with the choice of dontaudit-ing
read/write/execute from nautilus to everything or using this special
little bit of hackery to allowed access(2) to not spam the logs but to
get the right result.

You'll still get the read/write/execute denial if you try to DO anything
with the file.  Which you wouldn't if one were to do the dontaudit-ing
directly.

>  If nautilus cannot perform access checks on files then it will put a
> big
>  fat lock and cross label on the icon representing the file. 
That's right.  We want that lock to be able to be showed without
spamming the logs...

>  I think apps generally do access checks for legitimate reasons and
> not
>  for their health. 
except nautilus...

>  So to me this is useless. I would rather have seen a new av perm for
>  access(2) checks if that would have been at all possible. 
What would that gain us?  access(2) actually checks read/write/execute
and needs to return the correct results.  A new perm on access(2)
doesn't seem to apply...

> Now we have a av permission that is solely for dontaudit purposes.
> Sets
>  not such a good precedent. 
That's exactly what it is.  It is solely for dontaudit purposes.  It's a
strange little beast, but seemed a better solution than dontaudit for
actual attempted use of a file...

[Dominick Grift]

>  
>  > I think apps generally do access checks for legitimate reasons and not
>  > for their health.
>  
>  except nautilus... 
I actually have nautilus confined so i can actually verify/confirm all
this. I will do that and get back to you with results

[Dominick Grift]

On Tue, 2013-07-09 at 14:13 -0400, Eric Paris wrote:
>  On Tue, 2013-07-09 at 19:35 +0200, Dominick Grift wrote:
>  > On Tue, 2013-07-09 at 12:37 -0400, Eric Paris wrote:
>  > > On Tue, 2013-07-09 at 18:06 +0200, Dominick Grift wrote:
>  > > > On Tue, 2013-07-09 at 11:21 -0400, Daniel J Walsh wrote:
>  > > > > On 07/09/2013 10:27 AM, Dominick Grift wrote:
>  > > > > > On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
>  > > > > >> On 07/09/13 21:06, Ed Greshko wrote:
>  > > > > >> 
>  > > > > >> 
>  > > > > >> Sorry to be responding to myself....but....
>  > > > > >> 
>  > > > > >> It seems this AVC is the relevant one since /run is on
> tmpfs.
>  > > > > >>> 
>  > > > > >>> type=AVC msg=audit(1373375040.246:775): avc:  denied  {
> write } for
>  > > > > >>> pid=3820 comm="fail2ban-client"
> name="fail2ban" dev="tmpfs" ino=28732
>  > > > > >>> scontext=system_u:system_r:fail2ban_client_t:s0
>  > > > > >>> tcontext=system_u:object_r:fail2ban_var_run_t:s0
> tclass=dir
>  > > > > >> 
>  > > > > >> Not being fluent in selinux....  Would this be a bug in the
> fail2ban
>  > > > > >> policy module....  Or, something else?
>  > > > > >> 
>  > > > > > 
>  > > > > > yes a bug in the fail2ban policy module
>  > > > > > 
>  > > > > > either the fail2ban client checks to see if /run/fail2ban is
> writable or it
>  > > > > > actually wants to create something in there ( but there is
> currently no
>  > > > > > trace of the latter)
>  > > > 
>  > > > I noticed that fedora uses the audit_access av perm wrong ( at least to
>  > > > the best of my knowledge)
>  > > > 
>  > > > What fedora does:
>  > > > 
>  > > > dontaudit somedomain_t somefile_t:file audit_access;
>  > > > 
>  > > > How i believe it should be used:
>  > > > 
>  > > > dontaudit somedomain_t somefile_t:file write;
>  > > > allow somedomain_t somefile_t:file audit_access;
>  > > > 
>  > > > Although, and i have not checked this, it sometimes seems that it does
>  > > > not work either way. I still need to verify that. ( i might actually do
>  > > > that now)
>  > > 
>  > > It is using it correctly.  audit_access is weird and special..
>  > > 
>  > > allow for the perm audit_access means nothing at all...
>  > > 
>  > > dontaudit somedomain_t somefile_t:file audit_access;
>  > > 
>  > > means we don't audit failures in the access(2) syscall, but we do audit
>  > > failures on open/read/write...
>  > > 
>  > > We added this because nautilus does access(2) checks on every file in
>  > > the world to decide how to display it on the screen.  We didn't want to
>  > > hide users actually trying to open the file for read/write, but did want
>  > > to hide all of the 'denials' from access(2)
>  > > 
>  > > Disabling dontaudit should make things show up even for access(2)....
>  > 
>  > So now that i know how to use it. it raises other questions.
>  
>  It is very very weird.  I agree.
>  
>  > Isnt silently denying access checks the world upside-down? If it should
>  > not do access checks then should it not be fixed in the component rather
>  > than silently hidden in policy.
>  
>  You can't 'fix' nautilis.  It needs to ask if it has read/write/execute
>  permission to do its job.  So I'm left with the choice of dontaudit-ing
>  read/write/execute from nautilus to everything or using this special
>  little bit of hackery to allowed access(2) to not spam the logs but to
>  get the right result.
>  
>  You'll still get the read/write/execute denial if you try to DO anything
>  with the file.  Which you wouldn't if one were to do the dontaudit-ing
>  directly.
>  
>  > If nautilus cannot perform access checks on files then it will put a big
>  > fat lock and cross label on the icon representing the file.
>  
>  That's right.  We want that lock to be able to be showed without
>  spamming the logs...
>  
>  > I think apps generally do access checks for legitimate reasons and not
>  > for their health.
>  
>  except nautilus... 
Ok yes, it is starting to make a little sense to me. Although to me it
still doesnt seem quite worth it because if nautilus wants to for
example really execute or write a file then it would first need to be
able to open it.

and you know similar stuff is also happening with leaked fds in a sense.
where legitimate read writes are dontaudited because they may be related
to leaks ( which they often arent )

so for example:
# sesearch --dontaudit -s domain -t domain -c unix_stream_socket -p
read,write | grep " domain domain"
   dontaudit domain domain : unix_stream_socket { read write } ; 

i guess in a perfect world we would have a "audit_access" for that as
well so that legitimate { read write } would be logged while ones
related to leaked fd would be dontaudited ( but i bet thats technically
impossible).

But anyways i get the point now and i dont think i will use it much.

I tried it with nautilus and i was able to just dontaudit the checks
with no problems so far and no need for audit_access ( although i did
changed it now to audit_access just because i can )

Thanks for having this discussion with me