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

[Antonio Olivares]

Dear folks,

The title has been reported as NOT A BUG, but it is annoying :(
without doing anything but logging in, the setroubleshooter kicks in and displays the
message.  I have tried numerous times to report it, but it came back empty.  Then I click
enough times and see that it is there, but it is NOT A BUG :(, I don't agree but
can't do shite.

--- Running report_Bugzilla ---
Logging into Bugzilla at https://bugzilla.redhat.com
Checking for duplicates
Bug is already reported: 812100
Logging out
Status: CLOSED NOTABUG https://bugzilla.redhat.com/show_bug.cgi?id=812100

--- Running report_Bugzilla ---
This problem was already reported to Bugzilla (see
'https://bugzilla.redhat.com/show_bug.cgi?id=812100'). Do you still want to create
a new bug? NO


SELinux is preventing dmesg from 'read' accesses on the file /etc/ld.so.cache.

*****  Plugin restorecon (94.8 confidence) suggests  *************************

If you want to fix the label. 
/etc/ld.so.cache default label should be ld_so_cache_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /etc/ld.so.cache

*****  Plugin catchall_labels (5.21 confidence) suggests  ********************

If you want to allow dmesg to have read access on the ld.so.cache file
Then you need to change the label on /etc/ld.so.cache
Do
# semanage fcontext -a -t FILE_TYPE '/etc/ld.so.cache'
where FILE_TYPE is one of the following: cpu_online_t, afs_cache_t, abrt_helper_exec_t,
textrel_shlib_t, rpm_script_tmp_t, user_cron_spool_t, puppet_tmp_t, ld_so_cache_t,
abrt_var_run_t, udev_var_run_t, sysctl_kernel_t, abrt_var_run_t, sysctl_crypto_t,
locale_t, dmesg_t, proc_t, sysfs_t, dmesg_exec_t, abrt_t, lib_t, ld_so_t. 
Then execute: 
restorecon -v '/etc/ld.so.cache'


*****  Plugin catchall (1.44 confidence) suggests  ***************************

If you believe that dmesg should be allowed read access on the ld.so.cache file by
default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep dmesg /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:dmesg_t:s0
Target Context                unconfined_u:object_r:etc_t:s0
Target Objects                /etc/ld.so.cache [ file ]
Source                        dmesg
Source Path                   dmesg
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           glibc-2.15-32.fc17.i686
Policy RPM                    selinux-policy-3.10.0-116.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux acer-aspire-1 3.3.2-1.fc17.i686 #1 SMP Fri
                              Apr 13 21:06:40 UTC 2012 i686 i686
Alert Count                   1
First Seen                    Thu 19 Apr 2012 09:30:20 PM CDT
Last Seen                     Thu 19 Apr 2012 09:30:20 PM CDT
Local ID                      db50d35a-1a8c-4e53-a4ae-98765dcb81db

Raw Audit Messages
type=AVC msg=audit(1334889020.147:6): avc:  denied  { read } for  pid=633
comm="dmesg" name="ld.so.cache" dev="dm-1" ino=54745
scontext=system_u:system_r:dmesg_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file


Hash: dmesg,dmesg_t,etc_t,file,read

audit2allowunable to open /sys/fs/selinux/policy:  Permission denied


audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied



What do I do, please advice.  I am getting annoyed, frustrated and I would hate to kill
off selinux, because I actually like it, but the NOT A BUG does bother me.  I have had the
past three or four days dealing with this, and now I am finally doing something about it
:(

Thanks for listening.  

Regards,


Antonio

[Miroslav Grepl]

On 04/20/2012 04:42 AM, Antonio Olivares wrote:
>  Dear folks,
>
>  The title has been reported as NOT A BUG, but it is annoying :(
>  without doing anything but logging in, the setroubleshooter kicks in and displays the
> message.  I have tried numerous times to report it, but it came back empty.  Then I click
> enough times and see that it is there, but it is NOT A BUG :(, I don't agree but
> can't do shite.
>
>  --- Running report_Bugzilla ---
>  Logging into Bugzilla at https://bugzilla.redhat.com
>  Checking for duplicates
>  Bug is already reported: 812100
>  Logging out
>  Status: CLOSED NOTABUG https://bugzilla.redhat.com/show_bug.cgi?id=812100
>
>  --- Running report_Bugzilla ---
>  This problem was already reported to Bugzilla (see
> 'https://bugzilla.redhat.com/show_bug.cgi?id=812100'). Do you still want to create
> a new bug? NO
>
>
>  SELinux is preventing dmesg from 'read' accesses on the file /etc/ld.so.cache.
>
>  *****  Plugin restorecon (94.8 confidence) suggests  *************************
>
>  If you want to fix the label.
>  /etc/ld.so.cache default label should be ld_so_cache_t.
>  Then you can run restorecon.
>  Do
>  # /sbin/restorecon -v /etc/ld.so.cache
>
>  *****  Plugin catchall_labels (5.21 confidence) suggests  ********************
>
>  If you want to allow dmesg to have read access on the ld.so.cache file
>  Then you need to change the label on /etc/ld.so.cache
>  Do
>  # semanage fcontext -a -t FILE_TYPE '/etc/ld.so.cache'
>  where FILE_TYPE is one of the following: cpu_online_t, afs_cache_t, abrt_helper_exec_t,
> textrel_shlib_t, rpm_script_tmp_t, user_cron_spool_t, puppet_tmp_t, ld_so_cache_t,
> abrt_var_run_t, udev_var_run_t, sysctl_kernel_t, abrt_var_run_t, sysctl_crypto_t,
> locale_t, dmesg_t, proc_t, sysfs_t, dmesg_exec_t, abrt_t, lib_t, ld_so_t.
>  Then execute:
>  restorecon -v '/etc/ld.so.cache'
>
>
>  *****  Plugin catchall (1.44 confidence) suggests  ***************************
>
>  If you believe that dmesg should be allowed read access on the ld.so.cache file by
> default.
>  Then you should report this as a bug.
>  You can generate a local policy module to allow this access.
>  Do
>  allow this access for now by executing:
>  # grep dmesg /var/log/audit/audit.log | audit2allow -M mypol
>  # semodule -i mypol.pp
>
>  Additional Information:
>  Source Context                system_u:system_r:dmesg_t:s0
>  Target Context                unconfined_u:object_r:etc_t:s0
>  Target Objects                /etc/ld.so.cache [ file ]
>  Source                        dmesg
>  Source Path                   dmesg
>  Port<Unknown>
>  Host                          (removed)
>  Source RPM Packages
>  Target RPM Packages           glibc-2.15-32.fc17.i686
>  Policy RPM                    selinux-policy-3.10.0-116.fc17.noarch
>  Selinux Enabled               True
>  Policy Type                   targeted
>  Enforcing Mode                Enforcing
>  Host Name                     (removed)
>  Platform                      Linux acer-aspire-1 3.3.2-1.fc17.i686 #1 SMP Fri
>                                 Apr 13 21:06:40 UTC 2012 i686 i686
>  Alert Count                   1
>  First Seen                    Thu 19 Apr 2012 09:30:20 PM CDT
>  Last Seen                     Thu 19 Apr 2012 09:30:20 PM CDT
>  Local ID                      db50d35a-1a8c-4e53-a4ae-98765dcb81db
>
>  Raw Audit Messages
>  type=AVC msg=audit(1334889020.147:6): avc:  denied  { read } for  pid=633
> comm="dmesg" name="ld.so.cache" dev="dm-1" ino=54745
> scontext=system_u:system_r:dmesg_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
>
>
>  Hash: dmesg,dmesg_t,etc_t,file,read
>
>  audit2allowunable to open /sys/fs/selinux/policy:  Permission denied
>
>
>  audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied
>
>
>
>  What do I do, please advice.  I am getting annoyed, frustrated and I would hate to kill
> off selinux, because I actually like it, but the NOT A BUG does bother me.  I have had the
> past three or four days dealing with this, and now I am finally doing something about it
> :(
>
>  Thanks for listening.
>
>  Regards,
>
>
>  Antonio
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
I have just reopened the
bug.

[Antonio Olivares]

>  > --
>  I have just reopened the bug.
>   
Thank you very much sir.  I appreciate your help and Dan's as well.  

Regards,


Antonio

[Daniel J Walsh]

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

Somehow /etc/ld.so.cache file got mislabeled? Was this an initial install?
Install from livecd? Running restorecon on /etc/ld.so.cache will fix the
label, as the setroubleshoot tells you. Does the file become mislabeled again?


If we could figure out how it got mislabeled we would gladly fixed it, if we
get one bug from one person reporting a file is mislabeled, and do not hear
about it from others, we assume it is a one off and tell the user to follow
what setroubleshoot told them to do. If we see it repeatedly or from multiple
users we will do our best to investigate what is going on.

We have a rule in policy now that says if any unconfined domain creates this
file it will get labeled correctly, This include unconfined_t, initrc_t,
rpm_t, rpm_script_t. So I do not know how it got mislabeled. Does the file
first get created with a different name and then renamed to /etc/ld.so.cache_t?


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk+RWJcACgkQrlYvE4MpobMJRgCdENsp4rd6tb/UFfjIam52Ky8Z
> Z18AoLhxWV9Sx9bs5xODr6TMVEYehH9H
> =kMEl
> -----END PGP SIGNATURE-----

[Antonio Olivares]

--- On Fri, 4/20/12, Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:

>  From: Daniel J Walsh <dwalsh(a)redhat.com&gt;
>  Subject: Re: https://bugzilla.redhat.com/show_bug.cgi?id=812100
>  To: "For testing and quality assurance of Fedora releases"
> <test(a)lists.fedoraproject.org&gt;
>  Cc: "Antonio Olivares" <olivares14031(a)yahoo.com&gt;, "Selinux List at
> Fedora Project" <selinux(a)lists.fedoraproject.org&gt;
>  Date: Friday, April 20, 2012, 5:37 AM
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Somehow /etc/ld.so.cache file got mislabeled? Was this an
>  initial install?
>  Install from livecd?  
Installed from nightly build before rc4 and/or beta was released.  

>  Running restorecon on /etc/ld.so.cache
>  will fix the
>  label, as the setroubleshoot tells you. Does the file become
>  mislabeled again? 
Will try it later tonight and see what happens. 

>  
>  
>  If we could figure out how it got mislabeled we would gladly
>  fixed it, if we
>  get one bug from one person reporting a file is mislabeled,
>  and do not hear
>  about it from others, we assume it is a one off and tell the
>  user to follow
>  what setroubleshoot told them to do. If we see it repeatedly
>  or from multiple
>  users we will do our best to investigate what is going on.
>  
>  We have a rule in policy now that says if any unconfined
>  domain creates this
>  file it will get labeled correctly, This include
>  unconfined_t, initrc_t,
>  rpm_t, rpm_script_t. So I do not know how it got mislabeled.
>  Does the file
>  first get created with a different name and then renamed to
>  /etc/ld.so.cache_t?
>   
Regards,


Antonio