Bug 714136 - SELinux is preventing /sbin/setfiles from 'mac_admin' accesses on the capability2 Unknown.
Summary: SELinux is preventing /sbin/setfiles from 'mac_admin' accesses on the capabil...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:1dc43931c1c...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-17 12:07 UTC by Frank Murphy
Modified: 2020-08-03 16:37 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-11-21 16:57:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
serial console output (26.71 KB, text/plain)
2011-06-17 16:18 UTC, Frank Murphy
no flags Details
Screencap policy 26 (11.65 KB, image/png)
2011-06-18 10:15 UTC, Frank Murphy
no flags Details
Relabel attaempt (16.24 KB, image/png)
2011-06-20 07:00 UTC, Frank Murphy
no flags Details
fixfiles-restore (14.96 KB, image/png)
2011-06-23 13:29 UTC, Frank Murphy
no flags Details

Description Frank Murphy 2011-06-17 12:07:46 UTC
SELinux is preventing /sbin/setfiles from 'mac_admin' accesses on the capability2 Unknown.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that setfiles should be allowed mac_admin access on the Unknown capability2 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 restorecon /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:setfiles_t:s0
Target Context                system_u:system_r:setfiles_t:s0
Target Objects                Unknown [ capability2 ]
Source                        restorecon
Source Path                   /sbin/setfiles
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           policycoreutils-2.0.86-13.fc16
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-28.fc16
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed)
                              3.0-0.rc3.git0.3.fc16.x86_64 #1 SMP Tue Jun 14
                              17:13:27 UTC 2011 x86_64 x86_64
Alert Count                   5
First Seen                    Thu 16 Jun 2011 11:13:52 IST
Last Seen                     Thu 16 Jun 2011 11:13:55 IST
Local ID                      1ca65013-6291-4367-b988-08e42b8ecb9c

Raw Audit Messages
type=AVC msg=audit(1308219235.258:63): avc:  denied  { mac_admin } for  pid=1711 comm="restorecon" capability=33  scontext=system_u:system_r:setfiles_t:s0 tcontext=system_u:system_r:setfiles_t:s0 tclass=capability2


type=SYSCALL msg=audit(1308219235.258:63): arch=x86_64 syscall=lsetxattr success=no exit=EINVAL a0=7f2c7f3d6fe0 a1=7f2c7cb6afeb a2=7f2c7f76e1c0 a3=26 items=0 ppid=1493 pid=1711 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=restorecon exe=/sbin/setfiles subj=system_u:system_r:setfiles_t:s0 key=(null)

Hash: restorecon,setfiles_t,setfiles_t,capability2,mac_admin

audit2allow

#============= setfiles_t ==============
allow setfiles_t self:capability2 mac_admin;

audit2allow -R

#============= setfiles_t ==============
allow setfiles_t self:capability2 mac_admin;

Comment 1 Dominick Grift 2011-06-17 12:29:09 UTC
I suspect it is trying to reset the context of some location to or from a type that does not or no longer exists.

Do you have any custom file context specifications? In dmesg, do you get any notices about invalid types?

Would you be able to reproduce this after a full relabel of the file system? "touch /.autorelabel && reboot"

Comment 2 Frank Murphy 2011-06-17 16:17:45 UTC
(In reply to comment #1)

> 
> Would you be able to reproduce this after a full relabel of the file system?
> "touch /.autorelabel && reboot"

has frozen at the point of attached "relabel", this is immediately on reboot.
There are no custom *.pp files on the box.

Comment 3 Frank Murphy 2011-06-17 16:18:46 UTC
Created attachment 505307 [details]
serial console output

Comment 4 Dominick Grift 2011-06-17 16:23:44 UTC
I guess that functionality has not been implemented yet. Would you be able to reproduce it after running fixfiles restore in permissive mode?

Comment 5 Daniel Walsh 2011-06-17 17:43:47 UTC
This looks like you are attempting to put down labels that the kernel does not understand.

Perhaps something went wrong with your policy rebuild.

Could you attempt in permissive mode

# yum reinstall selinux-policy-targeted

And see if anything breaks.

Comment 6 Frank Murphy 2011-06-18 09:38:04 UTC
(In reply to comment #5)
> This looks like you are attempting to put down labels that the kernel does not
> understand.
> 
> Perhaps something went wrong with your policy rebuild.
> 
> Could you attempt in permissive mode
> 
> # yum reinstall selinux-policy-targeted
> 
> And see if anything breaks.


rebooted from rescue dvd enforcing=0
yum reinstall selinux-policy-targeted (3.9.16-29.1.fc16)
no errors shown.

Comment 7 Frank Murphy 2011-06-18 09:43:31 UTC
(In reply to comment #4)
> I guess that functionality has not been implemented yet. Would you be able to
> reproduce it after running fixfiles restore in permissive mode?

rebooted from dvd rescue enforcing=0

fixfiles restore (1.5 lines of asterisks)

reboot from hd
still freezes at "Started Recreate Volatile Files and Directories"

enforcing=0, different kernels, no difference.

Only overkill with selinux=0, gets a complete boot.

Will test from DVD with
rpm -e --nodeps selinux-policy-targeted
yum install "" "".

Will be back.

Comment 8 Frank Murphy 2011-06-18 10:15:02 UTC
Created attachment 505377 [details]
Screencap policy 26

as per comment 7:

screencap image shows "cannot downgrade policy.26"

Comment 9 Frank Murphy 2011-06-20 07:00:31 UTC
Created attachment 505536 [details]
Relabel attaempt

After much ado.
Have got as far as attempting to relabel entire system as permissive.

Are the avc before "Started Recreate Volatile Files and Directories"

preventing a full relabel?

Comment 10 Daniel Walsh 2011-06-22 20:19:05 UTC
No they are probably just permissive errors.   IE it is the kernel telling you that these AVC's were generated at boot.  

Did you actually see the relabel happen?  Lots of "*" on the screen?

Comment 11 Frank Murphy 2011-06-22 22:13:26 UTC
(In reply to comment #10)
> No they are probably just permissive errors.   IE it is the kernel telling you
> that these AVC's were generated at boot.  
> 
> Did you actually see the relabel happen?  Lots of "*" on the screen?

No.

Comment 12 Daniel Walsh 2011-06-23 12:56:00 UTC
Frank if you can login in permissive mode "enforcing=0"

Run 

# fixfiles restore

And see if this relabels the system

Comment 13 Frank Murphy 2011-06-23 13:28:15 UTC
(In reply to comment #12)
> Frank if you can login in permissive mode "enforcing=0"
> 
> Run 
> 
> # fixfiles restore
> 
> And see if this relabels the system


1: Booting from hd enforcing=0 stalls as per, relabel image.

2: Booting from rescue media with enforcing=0, "fixfiles restore",
gives as per attached image fixfiles-restor.png


Currently selinux disabled going by /etc/selinux/config

Comment 14 Frank Murphy 2011-06-23 13:29:01 UTC
Created attachment 506235 [details]
fixfiles-restore

Comment 15 Daniel Walsh 2011-06-23 13:34:20 UTC
Ok Frank, fixfiles-restore will not work unless SELinux is enabled.

But I think you might have a screwed up selinux-policy-targeted install.

# rm -rf /etc/selinux/targeted
# yum reinstall selinux-policy-targeted

modify /etc/selinux/config to put it in permissive mode, now see if relabel happens on reboot.

If not try the "fixfiles restore" again.

Comment 16 Matt Fagnani 2020-08-03 16:37:23 UTC
Similar problem has been detected:

I'm using a Fedora Rawhide KDE Plasma spin installation updated to 2020-8-3. I ran 
sudo dnf upgrade https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.14.6/23.fc33/noarch/selinux-policy-3.14.6-23.fc33.noarch.rpm https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.14.6/23.fc33/noarch/selinux-policy-targeted-3.14.6-23.fc33.noarch.rpm

restorecon was denied the mac_admin capability during the update process which I haven't seen before. The dnf output showed an error in the selinux-policy-targeted post-install scriplet as follows.

Upgrading        : selinux-policy-targeted-3.14.6-23.fc33.noarch                                 2/4 
  Running scriptlet: selinux-policy-targeted-3.14.6-23.fc33.noarch                                 2/4 
Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/100/kdbus/cil:4
/usr/sbin/semodule:  Failed!



hashmarkername: setroubleshoot
kernel:         5.8.0-0.rc7.1.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-23.fc33.noarch
reason:         SELinux is preventing restorecon from using the 'mac_admin' capabilities.
type:           libreport


Note You need to log in before you can comment on or make changes to this bug.