Selinux blocks system calls

[Vadym Chepkov]

Hi,

I stumbled on a case in RHEL7, where selinux blocks calls to systemd
I know it's SELinux, because everything work properly after setenforce 0

I added a simple manifest rules to puppet:

exec { 'update TZ':
  command => "/bin/timedatectl set-timezone ${timezone}",
  unless  => "/bin/timedatectl status | /bin/grep -q ${timezone}",
}

what's interesting, even after I ran

semodule --disable_dontaudit --build

I don't see any denials.

But then I created a simple cron job :

# cat /etc/cron.d/debug

* * * * * root /bin/timedatectl status &> /tmp/timedatectl.status

# cat /tmp/timedatectl.status

Failed to issue method call: Did not receive a reply. Possible causes
include: the remote application did not send a reply, the message bus
security policy blocked the reply, the reply timeout expired, or the
network connection was broken.

So it's not only puppet related.

Is this intended behavior? Some boolean I have to change?


Thanks,

Vadym

[Milos Malik]

Hi Vadym,

here are 2 bugs which describe similar symptoms:
 * https://bugzilla.redhat.com/show_bug.cgi?id=1014315 (Fedora)
 * https://bugzilla.redhat.com/show_bug.cgi?id=1132411 (RHEL-7)

Milos Malik

----- Original Message -----
>  Hi,
>  
>  I stumbled on a case in RHEL7, where selinux blocks calls to systemd
>  I know it's SELinux, because everything work properly after setenforce 0
>  
>  I added a simple manifest rules to puppet:
>  
>  exec { 'update TZ':
>    command => "/bin/timedatectl set-timezone ${timezone}",
>    unless  => "/bin/timedatectl status | /bin/grep -q ${timezone}",
>  }
>  
>  what's interesting, even after I ran
>  
>  semodule --disable_dontaudit --build
>  
>  I don't see any denials.
>  
>  But then I created a simple cron job :
>  
>  # cat /etc/cron.d/debug
>  
>  * * * * * root /bin/timedatectl status &> /tmp/timedatectl.status
>  
>  # cat /tmp/timedatectl.status
>  
>  Failed to issue method call: Did not receive a reply. Possible causes
>  include: the remote application did not send a reply, the message bus
>  security policy blocked the reply, the reply timeout expired, or the
>  network connection was broken.
>  
>  So it's not only puppet related.
>  
>  Is this intended behavior? Some boolean I have to change?
>  
>  
>  Thanks,
>  
>  Vadym
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Vadym Chepkov]

I don't have access to RHEL7 case. Should I open a new case? It is
possibility related, but I can even get the current status and as I said,
no avc denials.

Thanks,
Vadym
On Nov 24, 2014 2:37 AM, "Milos Malik" <mmalik(a)redhat.com&gt; wrote:

>  Hi Vadym,
>
>  here are 2 bugs which describe similar symptoms:
>   * https://bugzilla.redhat.com/show_bug.cgi?id=1014315 (Fedora)
>   * https://bugzilla.redhat.com/show_bug.cgi?id=1132411 (RHEL-7)
>
>  Milos Malik
>
>  ----- Original Message -----
>  > Hi,
>  >
>  > I stumbled on a case in RHEL7, where selinux blocks calls to systemd
>  > I know it's SELinux, because everything work properly after setenforce 0
>  >
>  > I added a simple manifest rules to puppet:
>  >
>  > exec { 'update TZ':
>  >   command => "/bin/timedatectl set-timezone ${timezone}",
>  >   unless  => "/bin/timedatectl status | /bin/grep -q ${timezone}",
>  > }
>  >
>  > what's interesting, even after I ran
>  >
>  > semodule --disable_dontaudit --build
>  >
>  > I don't see any denials.
>  >
>  > But then I created a simple cron job :
>  >
>  > # cat /etc/cron.d/debug
>  >
>  > * * * * * root /bin/timedatectl status &> /tmp/timedatectl.status
>  >
>  > # cat /tmp/timedatectl.status
>  >
>  > Failed to issue method call: Did not receive a reply. Possible causes
>  > include: the remote application did not send a reply, the message bus
>  > security policy blocked the reply, the reply timeout expired, or the
>  > network connection was broken.
>  >
>  > So it's not only puppet related.
>  >
>  > Is this intended behavior? Some boolean I have to change?
>  >
>  >
>  > Thanks,
>  >
>  > Vadym
>  >
>  > --
>  > selinux mailing list
>  > selinux(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/selinux
>

[jiun bookworm]

Vadym,
A while back while writing policy for an app that forks,  i got silent
denials that were not logged in the audit.log, so i could not tell what
new selinux permissions to add to the policy,  but after some trial and
error, i stumbled on fork permissions,  and everything was ok after
adding them.  Seems like selinux is not logging some denials,
Guys who know more out there care to  say something?

Jiun.

On Mon, Nov 24, 2014 at 10:45 PM, Vadym Chepkov <vchepkov(a)gmail.com&gt; wrote:

>  I don't have access to RHEL7 case. Should I open a new case? It
> is
>  possibility related, but I can even get the current status and as I said,
>  no avc denials.
>
>  Thanks,
>  Vadym
>  On Nov 24, 2014 2:37 AM, "Milos Malik" <mmalik(a)redhat.com&gt; wrote:
>
> > Hi Vadym,
> >
> > here are 2 bugs which describe similar symptoms:
> >  * https://bugzilla.redhat.com/show_bug.cgi?id=1014315 (Fedora)
> >  * https://bugzilla.redhat.com/show_bug.cgi?id=1132411 (RHEL-7)
> >
> > Milos Malik
> >
> > ----- Original Message -----
> > > Hi,
> > >
> > > I stumbled on a case in RHEL7, where selinux blocks calls to systemd
> > > I know it's SELinux, because everything work properly after setenforce 0
> > >
> > > I added a simple manifest rules to puppet:
> > >
> > > exec { 'update TZ':
> > >   command => "/bin/timedatectl set-timezone ${timezone}",
> > >   unless  => "/bin/timedatectl status | /bin/grep -q ${timezone}",
> > > }
> > >
> > > what's interesting, even after I ran
> > >
> > > semodule --disable_dontaudit --build
> > >
> > > I don't see any denials.
> > >
> > > But then I created a simple cron job :
> > >
> > > # cat /etc/cron.d/debug
> > >
> > > * * * * * root /bin/timedatectl status &> /tmp/timedatectl.status
> > >
> > > # cat /tmp/timedatectl.status
> > >
> > > Failed to issue method call: Did not receive a reply. Possible causes
> > > include: the remote application did not send a reply, the message bus
> > > security policy blocked the reply, the reply timeout expired, or the
> > > network connection was broken.
> > >
> > > So it's not only puppet related.
> > >
> > > Is this intended behavior? Some boolean I have to change?
> > >
> > >
> > > Thanks,
> > >
> > > Vadym
> > >
> > > --
> > > selinux mailing list
> > > selinux(a)lists.fedoraproject.org
> > > https://admin.fedoraproject.org/mailman/listinfo/selinux
> >
>
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>

[Milos Malik]

Hi all,

AFAIK silent denials could be caused by:
 * dontaudit rules
 * the audit daemon is not running or is stuck
 * lack of free space on partition where /var/log/audit directory is located
 * insufficient ausearch parameters

Dontaudit rules can be removed from active policy by "semodule -DB" command. If
you want to get them back, use "semodule -B".
When audit daemon is not running or is stuck, then audit messages are not logged. Try to
restart the audit daemon.
When the partition, which holds /var/log/audit directory, has less than 50 MB of free
space, then audit daemon stops logging audit messages.
Always use "ausearch -m avc -m user_avc -m selinux_err -i" to see all SELinux
related audit messages.
When you don't see SELinux denials, but you know that SELinux denied some actions,
always look into /var/log/messages file, check the output of dmesg or see the console.

Milos Malik

----- Original Message -----
>  Vadym,
>  A while back while writing policy for an app that forks,  i got silent
>  denials that were not logged in the audit.log, so i could not tell what
>  new selinux permissions to add to the policy,  but after some trial and
>  error, i stumbled on fork permissions,  and everything was ok after
>  adding them.  Seems like selinux is not logging some denials,
>  Guys who know more out there care to  say something?
>  
>  Jiun.
>  
>  On Mon, Nov 24, 2014 at 10:45 PM, Vadym Chepkov <vchepkov(a)gmail.com&gt; wrote:
>  
>  > I don't have access to RHEL7 case. Should I open a new case? It is
>  > possibility related, but I can even get the current status and as I said,
>  > no avc denials.
>  >
>  > Thanks,
>  > Vadym
>  > On Nov 24, 2014 2:37 AM, "Milos Malik" <mmalik(a)redhat.com&gt; wrote:
>  >
>  >> Hi Vadym,
>  >>
>  >> here are 2 bugs which describe similar symptoms:
>  >>  * https://bugzilla.redhat.com/show_bug.cgi?id=1014315 (Fedora)
>  >>  * https://bugzilla.redhat.com/show_bug.cgi?id=1132411 (RHEL-7)
>  >>
>  >> Milos Malik
>  >>
>  >> ----- Original Message -----
>  >> > Hi,
>  >> >
>  >> > I stumbled on a case in RHEL7, where selinux blocks calls to systemd
>  >> > I know it's SELinux, because everything work properly after setenforce
> 0
>  >> >
>  >> > I added a simple manifest rules to puppet:
>  >> >
>  >> > exec { 'update TZ':
>  >> >   command => "/bin/timedatectl set-timezone ${timezone}",
>  >> >   unless  => "/bin/timedatectl status | /bin/grep -q
> ${timezone}",
>  >> > }
>  >> >
>  >> > what's interesting, even after I ran
>  >> >
>  >> > semodule --disable_dontaudit --build
>  >> >
>  >> > I don't see any denials.
>  >> >
>  >> > But then I created a simple cron job :
>  >> >
>  >> > # cat /etc/cron.d/debug
>  >> >
>  >> > * * * * * root /bin/timedatectl status &> /tmp/timedatectl.status
>  >> >
>  >> > # cat /tmp/timedatectl.status
>  >> >
>  >> > Failed to issue method call: Did not receive a reply. Possible causes
>  >> > include: the remote application did not send a reply, the message bus
>  >> > security policy blocked the reply, the reply timeout expired, or the
>  >> > network connection was broken.
>  >> >
>  >> > So it's not only puppet related.
>  >> >
>  >> > Is this intended behavior? Some boolean I have to change?
>  >> >
>  >> >
>  >> > Thanks,
>  >> >
>  >> > Vadym
>  >> >
>  >> > --
>  >> > selinux mailing list
>  >> > selinux(a)lists.fedoraproject.org
>  >> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>  >>
>  >
>  > --
>  > selinux mailing list
>  > selinux(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/selinux
>  >
>