Updating selinux-policy-targeted Causes SELinux Denials

[Richi Plana]

Hi,

Should I be concerned that every time an update to
selinux-policy-targeted occurs, it causes actions that the current
running SELinux seems to prevent? I'm talking about SELinux
preventing /usr/sbin/semodule (semanage_t) and /sbin/restorecon
(restorecon_t) "write"ing to a pipe with label "rpm_t".

Are these actions legal? And does SELinux preventing them cause an error
in the actual install? Or should these just be treated as warnings?

I'm guessing that the selinux applications are just trying to
communicate back to the RPM process. I'm wondering if there's anything
important in that communication that should be allowed, or if not, there
must be some way to clean this up.

(If this isn't the right place to ask, could someone redirect me to the
correct one?)
--

Richi Plana

[Daniel J Walsh]

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

Richi Plana wrote:
>  Hi,
>  
>  Should I be concerned that every time an update to
>  selinux-policy-targeted occurs, it causes actions that the current
>  running SELinux seems to prevent? I'm talking about SELinux
>  preventing /usr/sbin/semodule (semanage_t) and /sbin/restorecon
>  (restorecon_t) "write"ing to a pipe with label "rpm_t".
>  
>  Are these actions legal? And does SELinux preventing them cause an error
>  in the actual install? Or should these just be treated as warnings?
>  
>  I'm guessing that the selinux applications are just trying to
>  communicate back to the RPM process. I'm wondering if there's anything
>  important in that communication that should be allowed, or if not, there
>  must be some way to clean this up.
>  
>  (If this isn't the right place to ask, could someone redirect me to the
>  correct one?)
>  --
>  
>  Richi Plana
>   
No,  I am hoping to eliminate a lot of these in the future.  What these
avc's are referring to is the redirection of stdout/stderr.  When rpm is
running an update it redirects the terminal output to its fifo_files. So
any confined domain that runs as part of a post install script will
check whether it has access to stdin, stdout, stderr on the terminal or
whatever is acting as the terminal.  Since these confined domains do not
have policy allowing them to talk to pipes owned by rpm, the kernel
generates avc messages and closes the file descriptors and replaces them
with open file descriptors to /dev/null.  The apps will continue running
and complete successfully, but ugly avc messages are generated.  In
Updates to policy I am going to globally start dontauditing these access.


# Allow all domains to use fds past to them
allow domain domain:fd use;
optional_policy(`
	rpm_dontaudit_rw_pipes(domain)
')

Should be in Fedora 8 and beyond as well as in the next update to Fedora 7.

Redirection of Stdout/Stderr account for the largest percentage of
SELinux AVC's and most are just noice.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFHMIVQrlYvE4MpobMRAt+6AJ0UGeJjIz94iqDNM5HHGsuCJGJgrgCgqpWK
> 0eaM8OKv3PG2x+sVXLV9Tl4=
> =Fh29
> -----END PGP SIGNATURE-----

[Paul Howarth]

Daniel J Walsh wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Richi Plana wrote:
> > Hi,
> >
> > Should I be concerned that every time an update to
> > selinux-policy-targeted occurs, it causes actions that the current
> > running SELinux seems to prevent? I'm talking about SELinux
> > preventing /usr/sbin/semodule (semanage_t) and /sbin/restorecon
> > (restorecon_t) "write"ing to a pipe with label "rpm_t".
> >
> > Are these actions legal? And does SELinux preventing them cause an error
> > in the actual install? Or should these just be treated as warnings?
> >
> > I'm guessing that the selinux applications are just trying to
> > communicate back to the RPM process. I'm wondering if there's anything
> > important in that communication that should be allowed, or if not, there
> > must be some way to clean this up.
> >
> > (If this isn't the right place to ask, could someone redirect me to the
> > correct one?)
> > --
> >
> > Richi Plana
> >
>  No,  I am hoping to eliminate a lot of these in the future.  What these
>  avc's are referring to is the redirection of stdout/stderr.  When rpm is
>  running an update it redirects the terminal output to its fifo_files. So
>  any confined domain that runs as part of a post install script will
>  check whether it has access to stdin, stdout, stderr on the terminal or
>  whatever is acting as the terminal.  Since these confined domains do not
>  have policy allowing them to talk to pipes owned by rpm, the kernel
>  generates avc messages and closes the file descriptors and replaces them
>  with open file descriptors to /dev/null.  The apps will continue running
>  and complete successfully, but ugly avc messages are generated.  In
>  Updates to policy I am going to globally start dontauditing these access.
>  
>  
>  # Allow all domains to use fds past to them
>  allow domain domain:fd use;
>  optional_policy(`
>  	rpm_dontaudit_rw_pipes(domain)
>  ')
>  
>  Should be in Fedora 8 and beyond as well as in the next update to Fedora 7.
>  
>  Redirection of Stdout/Stderr account for the largest percentage of
>  SELinux AVC's and most are just noice. 
The net effect of this is to throw away any scriptlet output (e.g. error 
messages), isn't it? Whilst people running a GUI update tool won't see 
these anyway, us luddites that still use yum from the command line so as 
to see if there are any problems during an update won't be able to see 
this output.

Yes, I know that this doesn't represent a change from current policy; I 
usually add local policy to allow this output when I see the avcs, but 
if they're dontaudited then I won't see any hint of there being a problem.

Paul.

[Daniel J Walsh]

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

Paul Howarth wrote:
>  Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Richi Plana wrote:
> >> Hi,
> >>
> >> Should I be concerned that every time an update to
> >> selinux-policy-targeted occurs, it causes actions that the current
> >> running SELinux seems to prevent? I'm talking about SELinux
> >> preventing /usr/sbin/semodule (semanage_t) and /sbin/restorecon
> >> (restorecon_t) "write"ing to a pipe with label "rpm_t".
> >>
> >> Are these actions legal? And does SELinux preventing them cause an error
> >> in the actual install? Or should these just be treated as warnings?
> >>
> >> I'm guessing that the selinux applications are just trying to
> >> communicate back to the RPM process. I'm wondering if there's anything
> >> important in that communication that should be allowed, or if not, there
> >> must be some way to clean this up.
> >>
> >> (If this isn't the right place to ask, could someone redirect me to the
> >> correct one?)
> >> -- 
> >>
> >> Richi Plana
> >>
> > No,  I am hoping to eliminate a lot of these in the future.  What these
> > avc's are referring to is the redirection of stdout/stderr.  When rpm is
> > running an update it redirects the terminal output to its fifo_files. So
> > any confined domain that runs as part of a post install script will
> > check whether it has access to stdin, stdout, stderr on the terminal or
> > whatever is acting as the terminal.  Since these confined domains do not
> > have policy allowing them to talk to pipes owned by rpm, the kernel
> > generates avc messages and closes the file descriptors and replaces them
> > with open file descriptors to /dev/null.  The apps will continue running
> > and complete successfully, but ugly avc messages are generated.  In
> > Updates to policy I am going to globally start dontauditing these access.
> >
> >
> > # Allow all domains to use fds past to them
> > allow domain domain:fd use;
> > optional_policy(`
> >     rpm_dontaudit_rw_pipes(domain)
> > ')
> >
> > Should be in Fedora 8 and beyond as well as in the next update to
> > Fedora 7.
> >
> > Redirection of Stdout/Stderr account for the largest percentage of
> > SELinux AVC's and most are just noice.
>  
>  The net effect of this is to throw away any scriptlet output (e.g. error
>  messages), isn't it? Whilst people running a GUI update tool won't see
>  these anyway, us luddites that still use yum from the command line so as
>  to see if there are any problems during an update won't be able to see
>  this output.
>  
>  Yes, I know that this doesn't represent a change from current policy; I
>  usually add local policy to allow this output when I see the avcs, but
>  if they're dontaudited then I won't see any hint of there being a problem.
>  
>  Paul.
>   
Your right, I will change it to rpm_rw_pipes

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFHMjvbrlYvE4MpobMRAiNOAJ94NZPDegUO18Q2lSQZO7G25X+uygCfaxzm
> qTuEIkXteGRrmBX8lqGcm+E=
> =FZLG
> -----END PGP SIGNATURE-----