[clueless-user]Should I ignore or report this avc denial?

[Sergio]

Hello.
For quite some time I have this avc denial at boot time:

f17 kernel: [   24.589672] type=1400 audit(1348484525.104:4): avc:  denied  { mmap_zero }
for  pid=449 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023
tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect

I know it's for vbetool but it comes right after the video driver module is loaded
(don't know if it makes sense).

Should I leave it alone? Should I report to selinux-policy-targeted as a bug? Or maybe
create some policy to work around that?

Thank you.

[Dominick Grift]

On Wed, Sep 26, 2012 at 03:40:32PM -0700, Sergio wrote:
>  Hello.
>  For quite some time I have this avc denial at boot time:
>  
>  f17 kernel: [   24.589672] type=1400 audit(1348484525.104:4): avc:  denied  { mmap_zero }
> for  pid=449 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
>  
>  I know it's for vbetool but it comes right after the video driver module is loaded
> (don't know if it makes sense).
>  
>  Should I leave it alone? Should I report to selinux-policy-targeted as a bug? Or maybe
> create some policy to work around that? 
The policy configuration supports two options:

1. silently deny this: setsebool -P vbetool_mmap_zero_ignore on

or

2. allow this: setsebool -P mmap_low_allowed on



>  
>  Thank you.
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Daniel J Walsh]

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

On 09/27/2012 04:21 AM, Dominick Grift wrote:
>  On Wed, Sep 26, 2012 at 03:40:32PM -0700, Sergio wrote:
> > Hello. For quite some time I have this avc denial at boot time:
> > 
> > f17 kernel: [   24.589672] type=1400 audit(1348484525.104:4): avc:
> > denied  { mmap_zero } for  pid=449 comm="vbetool"
> > scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023
> > tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
> > 
> > I know it's for vbetool but it comes right after the video driver module
> > is loaded (don't know if it makes sense).
> > 
> > Should I leave it alone? Should I report to selinux-policy-targeted as a
> > bug? Or maybe create some policy to work around that?
>  
>  The policy configuration supports two options:
>  
>  1. silently deny this: setsebool -P vbetool_mmap_zero_ignore on
>  
>  or
>  
>  2. allow this: setsebool -P mmap_low_allowed on
>  
>  
>  
> > 
> > Thank you. -- 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 

A better solution is probably

yum remove vbetool

Since most people do not need it.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlBkOUgACgkQrlYvE4MpobMNfQCgl8a6nd7FVvghxniPQoOjPk1I
> AuUAn3whlGSMhhobvr7SikxiVC9NcO9p
> =0/Ab
> -----END PGP SIGNATURE-----

[Sergio]

>  >> Hello. For quite some time I have this avc denial
>  at boot time:
>  >> 
>  >> f17 kernel: [   24.589672] type=1400
>  audit(1348484525.104:4): avc:
>  >> denied  { mmap_zero } for  pid=449
>  comm="vbetool"
>  >>
>  scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023
>  >> tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023
>  tclass=memprotect
>  >> 
>  >> I know it's for vbetool but it comes right after
>  the video driver module
>  >> is loaded (don't know if it makes sense).
>  >> 
>  >> Should I leave it alone? Should I report to
>  selinux-policy-targeted as a
>  >> bug? Or maybe create some policy to work around
>  that?
>  > 
>  > The policy configuration supports two options:
>  > 
>  > 1. silently deny this: setsebool -P
>  vbetool_mmap_zero_ignore on
>  > 
>  > or
>  > 
>  > 2. allow this: setsebool -P mmap_low_allowed on
>  > 
>  > 
>  > 
>  
>  A better solution is probably
>  
>  yum remove vbetool
>  
>  Since most people do not need it. 
Thank you both.
I installed vbetool some time ago to troubleshoot suspend/hibernate issues.

[Sergio]

>  > > 
>  > > The policy configuration supports two options:
>  > > 
>  > > 1. silently deny this: setsebool -P
>  > vbetool_mmap_zero_ignore on
>  > > 
>  > > or
>  > > 
>  > > 2. allow this: setsebool -P mmap_low_allowed on
>  > > 
>  > > 
>  > > 
>  > 
>  > A better solution is probably
>  > 
>  > yum remove vbetool
>  > 
>  > Since most people do not need it.
>   
For the while I went with

# setsebool -P mmap_low_allowed on

And it's taking quite a while to complete the job. The command is using almost all of
my old Athlon CPU for quite some time already.

Is this normal?

Note: last selinux-policy-targeted update got stuck and I eventually had to stop it and
then complete it afterwards (with yum-complete-transaction).
Just saying to give a perspective. Maybe I should stop the setsebool process (not doing
anything now in case I get an answer)?

[Sergio]

>  For the while I went with
>  
>  # setsebool -P mmap_low_allowed on
>  
>  And it's taking quite a while to complete the job. The
>  command is using almost all of my old Athlon CPU for quite
>  some time already.
>  
>  Is this normal?
>  
>  Note: last selinux-policy-targeted update got stuck and I
>  eventually had to stop it and then complete it afterwards
>  (with yum-complete-transaction).
>  Just saying to give a perspective. Maybe I should stop the
>  setsebool process (not doing anything now in case I get an
>  answer)? 
Ok. It completed.

Thanks.

[Daniel J Walsh]

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

On 09/27/2012 10:34 AM, Sergio wrote:
>  
> >>> 
> >>> The policy configuration supports two options:
> >>> 
> >>> 1. silently deny this: setsebool -P
> >> vbetool_mmap_zero_ignore on
> >>> 
> >>> or
> >>> 
> >>> 2. allow this: setsebool -P mmap_low_allowed on
> >>> 
> >>> 
> >>> 
> >> 
> >> A better solution is probably
> >> 
> >> yum remove vbetool
> >> 
> >> Since most people do not need it.
> > 
>  
>  For the while I went with
>  
>  # setsebool -P mmap_low_allowed on
>  
>  And it's taking quite a while to complete the job. The command is using
>  almost all of my old Athlon CPU for quite some time already.
>  
>  Is this normal?
>  
>  Note: last selinux-policy-targeted update got stuck and I eventually had to
>  stop it and then complete it afterwards (with yum-complete-transaction). 
>  Just saying to give a perspective. Maybe I should stop the setsebool
>  process (not doing anything now in case I get an answer)? -- selinux
>  mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   

setsebool -P and semanage commands are slow, they are doing a full recompile
of all policy.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlBkZ9gACgkQrlYvE4MpobNjlACg126d4iWcQfOLy1055JRh7WMS
> 0tUAoMbWoZkCupG14MnpJjrIWogpcYR7
> =jHfD
> -----END PGP SIGNATURE-----

semanage slow (Should I ignore or report this avc denial?)

[Zdenek Pytela]

Daniel J Walsh pise:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  On 09/27/2012 10:34 AM, Sergio wrote:
>  > 
>  >>>> 
>  >>>> The policy configuration supports two options:
>  >>>> 
>  >>>> 1. silently deny this: setsebool -P
>  >>> vbetool_mmap_zero_ignore on
>  >>>> 
>  >>>> or
>  >>>> 
>  >>>> 2. allow this: setsebool -P mmap_low_allowed on
>  >>>> 
>  >>>> 
>  >>>> 
>  >>> 
>  >>> A better solution is probably
>  >>> 
>  >>> yum remove vbetool
>  >>> 
>  >>> Since most people do not need it.
>  >> 
>  > 
>  > For the while I went with
>  > 
>  > # setsebool -P mmap_low_allowed on
>  > 
>  > And it's taking quite a while to complete the job. The command is using
>  > almost all of my old Athlon CPU for quite some time already.
>  > 
>  > Is this normal?
>  > 
>  > Note: last selinux-policy-targeted update got stuck and I eventually had to
>  > stop it and then complete it afterwards (with yum-complete-transaction). 
>  > Just saying to give a perspective. Maybe I should stop the setsebool
>  > process (not doing anything now in case I get an answer)? -- selinux
>  > mailing list selinux(a)lists.fedoraproject.org 
>  > https://admin.fedoraproject.org/mailman/listinfo/selinux
>  > 
>  > 
>  
>  
>  setsebool -P and semanage commands are slow, they are doing a full recompile
>  of all policy. 
	OK, I understand this. But what's the reason to be
semanage boolean -l
much slower than
getsebool -a
No recompiling, just gathering the booleans default state and short summary
in addition to the second command.

-- 

--Zdenek Pytela, <pytela(a)phil.muni.cz&gt;

semanage slow (Should I ignore or report this avc denial?)

[Daniel J Walsh]

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

On 10/02/2012 09:21 AM, Zdenek Pytela wrote:
>  Daniel J Walsh pise:
> > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> > 
> > On 09/27/2012 10:34 AM, Sergio wrote:
> >> 
> >>>>> 
> >>>>> The policy configuration supports two options:
> >>>>> 
> >>>>> 1. silently deny this: setsebool -P
> >>>> vbetool_mmap_zero_ignore on
> >>>>> 
> >>>>> or
> >>>>> 
> >>>>> 2. allow this: setsebool -P mmap_low_allowed on
> >>>>> 
> >>>>> 
> >>>>> 
> >>>> 
> >>>> A better solution is probably
> >>>> 
> >>>> yum remove vbetool
> >>>> 
> >>>> Since most people do not need it.
> >>> 
> >> 
> >> For the while I went with
> >> 
> >> # setsebool -P mmap_low_allowed on
> >> 
> >> And it's taking quite a while to complete the job. The command is
> >> using almost all of my old Athlon CPU for quite some time already.
> >> 
> >> Is this normal?
> >> 
> >> Note: last selinux-policy-targeted update got stuck and I eventually
> >> had to stop it and then complete it afterwards (with
> >> yum-complete-transaction). Just saying to give a perspective. Maybe I
> >> should stop the setsebool process (not doing anything now in case I get
> >> an answer)? -- selinux mailing list selinux(a)lists.fedoraproject.org 
> >> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >> 
> >> 
> > 
> > 
> > setsebool -P and semanage commands are slow, they are doing a full
> > recompile of all policy.
>  OK, I understand this. But what's the reason to be semanage boolean -l much
>  slower than getsebool -a No recompiling, just gathering the booleans
>  default state and short summary in addition to the second command.
>   
Yes this is because semanage is doing a lot of initialization stuff that could
probably be avoided if we were a little smarter.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlBrL3gACgkQrlYvE4MpobNwwwCbBjKPyd+SslomlyJJHj3xggJv
> toYAnixNTm/kNynaC5fDi7QBGN8P5Qjt
> =vErS
> -----END PGP SIGNATURE-----