Bug 461778 - SELinux AVC when updating dumprd
SELinux AVC when updating dumprd
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Neil Horman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-10 11:10 EDT by Rich Johnson
Modified: 2008-09-16 11:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-12 15:37:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rich Johnson 2008-09-10 11:10:34 EDT
Description of problem:
  mount/umount trigger AVC when updating kdump's dumprd 

Version-Release number of selected component (if applicable):
  kexec-tools-1.102pre-21.el5_2.2
  selinux-policy-targeted-2.4.6-137.1.el5_2

How reproducible:


Steps to Reproduce:
1.  enable kdump & selinux during IPL/firstboot
2.  logon as root
3.  touch /etc/kdump.conf
4.  service kdump restart
  
Actual results:
time->Wed Sep 10 10:58:29 2008
type=SYSCALL msg=audit(1221058709.307:48): arch=c000003e syscall=59 success=yes exit=0 a0=301b150 a1=301b390 a2=302f2e0 a3=0 items=0 ppid=21248 pid=21249 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="mount" exe="/bin/mount" subj=root:system_r:mount_t:s0 key=(null)
type=AVC msg=audit(1221058709.307:48): avc:  denied  { read } for  pid=21249 comm="mount" path="/etc/kdump.conf" dev=md2 ino=5800527 scontext=root:system_r:mount_t:s0 tcontext=system_u:object_r:rpm_script_tmp_t:s0 tclass=file
----
time->Wed Sep 10 10:58:29 2008
type=SYSCALL msg=audit(1221058709.323:49): arch=c000003e syscall=59 success=yes exit=0 a0=30833f0 a1=3083ad0 a2=302f2e0 a3=0 items=0 ppid=19912 pid=21258 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="umount" exe="/bin/umount" subj=root:system_r:mount_t:s0 key=(null)
type=AVC msg=audit(1221058709.323:49): avc:  denied  { read } for  pid=21258 comm="umount" path="/etc/kdump.conf" dev=md2 ino=5800527 scontext=root:system_r:mount_t:s0 tcontext=system_u:object_r:rpm_script_tmp_t:s0 tclass=file


Expected results:
 clean execution; no avc

Additional info:
 dumprd appears to be built successfully.
Comment 1 Neil Horman 2008-09-10 13:45:23 EDT
this should be handled by the targete policy owner I believe

kdump needs to have rights to mount devices because it builds an initrd by loop mounting a file to populate it with kdump utilities (you can likely use the mkinitrd policy as a template for what we need rights for.  Thanks!
Comment 2 Daniel Walsh 2008-09-11 14:09:18 EDT
/etc/kdump.conf has the wrong context on it.  Who ever created it in a post install script needs to run restorecon on the finished program.
Comment 3 Neil Horman 2008-09-11 15:06:48 EDT
Then this is likely NOTABUG, since kdump.conf isn't created in %post.  Its listed as a source file in the srpm and specified as a %config file, which, after talking with eparis produces this label on his clean RHEL-5 machine:
ls -Z /etc/kdump.conf 
-rw-r--r--  root root system_u:object_r:etc_t          /etc/kdump.conf

Given that the label above is rpm_script_tmp_t, my guess is that you have removed the origional file that was provided in the kexec-tools package, and recreated it via a %post script in a subsequent custom rpm.  Either way the solution, as Dan points out, is to run restorecon
Comment 4 Rich Johnson 2008-09-12 12:54:06 EDT
(In reply to comment #3)
> Then this is likely NOTABUG, since kdump.conf isn't created in %post.  Its
> listed as a source file in the srpm and specified as a %config file, which,
> after talking with eparis produces this label on his clean RHEL-5 machine:
> ls -Z /etc/kdump.conf 
> -rw-r--r--  root root system_u:object_r:etc_t          /etc/kdump.conf
> 
> Given that the label above is rpm_script_tmp_t, my guess is that you have
> removed the origional file that was provided in the kexec-tools package, and
> recreated it via a %post script in a subsequent custom rpm.  Either way the
> solution, as Dan points out, is to run restorecon

Hmm.  I do have a %post script which uses 
  patch --forward -p0 <<THIS_HERE_DOC
--- /etc/kdump.conf  2008-03-02 10:36:50.000000000 -0500
+++ /etc/kdump.conf  2008-03-03 15:10:14.000000000 -0500
...

to address a reserved crash partition by UUID.

I think what you're telling me is that patch(1) is changing the file's context.  If so, isn't that a bug?

Executing a restorcon to the %post script implies that SELinux must be active when the kickstart is processed.   Is this the case?
Comment 5 Neil Horman 2008-09-12 15:37:43 EDT
Not to the best of my knoweldge, its not a bug.  if you strace the patch utility, you'll note that it creates a new temporary file to produce the patched file output, then it renames the origional file to <name>.orig and renames the temporary file to <name>.  So kdump.conf, based on your manipulation above is a new file, which inherits the context labels from the parent process, which in this case is rpm_script_tmp_t.  If you want to maintain the context  of the file, you should not create a new one.  I wouild suggest that, rather than use patch to manipulate the file, that instead you cat a file out to /tmp/somename, and then cp /tmp/somename /etc/kdump.conf.  That was when cp stats the target file, it will see its already there and open it with O_WRONLY|O_TRUNC, which should presere the origional context.

you are correct in that you need selinux active to run restorecon, so if your doing this in a %post script of an rpm during install, or in a kickstart file, thats a non-starter.  I would suggest the adjustment to your install procedure that I recommended above.  That will preserve the origional file context so you wont need restorecon.
Comment 6 Rich Johnson 2008-09-15 08:50:02 EDT
Fair enough.   However, from a system perspective, the behavior is it more than a bit counter-intuitive and is one more barrier to acceptance.   This in turn indicates that there is probably a flaw somewhere; though it may lie more with the implementation of patch.
Comment 7 Daniel Walsh 2008-09-16 11:53:02 EDT
restorecon will not blow up in a disabled machine it will just quietly exit.

Patch should maintain the context on the file, however if the file is created in /tmp and patched in /tmp it will have the context of rpm_script_tmp_t, if it is then mv'd to /etc it will retain that context.  If that is the case you need to run restorecon.

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