Bug 172355 - nash resume leaves a file handle to the swap device open
nash resume leaves a file handle to the swap device open
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-03 04:44 EST by Russell Coker
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-03 19:17:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to fix this bug (725 bytes, patch)
2005-11-03 04:57 EST, Russell Coker
no flags Details | Diff

  None (edit)
Description Russell Coker 2005-11-03 04:44:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.92 (like Gecko)

Description of problem:
The code in nash for the "resume" operation doesn't close the file handle for 
the swap device on error.  This is particularly problematic because an error 
on the "resume" corresponds to a regular boot.  Below are the SE Linux AVC 
messages which alerted me to this problem.  I'll attach a patch to nash.c to 
fix this bug next. 
  
audit(1131005829.612:2): avc:  denied  { use } for  pid=398 comm="hwclock"  
name="play-swap" dev=tmpfs ino=732 scontext=system_u:system_r:hwclock_t:s0  
tcontext=system_u:system_r:kernel_t:s0 tclass=fd  
audit(1131005829.612:3): avc:  denied  { read } for  pid=398 comm="hwclock"  
name="play-swap" dev=tmpfs ino=732 scontext=system_u:system_r:hwclock_t:s0  
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file  
audit(1131005838.793:4): avc:  denied  { read } for  pid=918 comm="restorecon"  
name="play-swap" dev=tmpfs ino=732 scontext=system_u:system_r:restorecon_t:s0  
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file  
  

Version-Release number of selected component (if applicable):
mkinitrd-5.0.8-1

How reproducible:
Always

Steps to Reproduce:
Do a default rawhide install and observe SE Linux AVC messages. 

Additional info:
Comment 1 Russell Coker 2005-11-03 04:57:15 EST
Created attachment 120680 [details]
patch to fix this bug

The code style of this patch may not suit your taste, but the patch shows what
needs to be done.
Comment 2 jan vestby 2005-11-06 19:35:11 EST
The way selinux treats this case is baffling, all read access is denied, yet a 
lot of processes open the file. I get (hda6 is swap partition): 
#lsof | grep hda 
init         1       root   55r      BLK        3,6                 573 /hda6 
udevd      406       root   55r      BLK        3,6                 573 /hda6 
kmodule    660       root   55r      BLK        3,6                 573 /hda6 
automount 2445       root   55r      BLK        3,6                 573 /hda6 
automount 2498       root   55r      BLK        3,6                 573 /hda6 
rpc.rquot 2565       root   55r      BLK        3,6                 573 /hda6 
exim      2618       exim   55r      BLK        3,6                 573 /hda6 
gpm       2628       root   55r      BLK        3,6                 573 /hda6 
crond     2637       root   55r      BLK        3,6                 573 /hda6 
xfs       2713        xfs   55r      BLK        3,6                 573 /hda6 
lisa      2722       root   55r      BLK        3,6                 573 /hda6 
atd       2739       root   55r      BLK        3,6                 573 /hda6 
prefdm    3031       root   55r      BLK        3,6                 573 /hda6 
gdm-binar 3057       root   55r      BLK        3,6                 573 /hda6 
 
regards  
Comment 3 Russell Coker 2005-11-06 21:15:52 EST
Is SE Linux in Enforcing mode?  Run "getenforce" to check. 
 
Due to a bug installs of rawhide have permissive by default. 
Comment 4 jan vestby 2005-11-08 17:36:10 EST
system is current rawhide (as far as yum will take it): 
# getenforce 
Enforcing 
 
Maybe these processes are scanning the dev directory and the "wrong" path of 
this file is so confusing that the file cannot even be dropped ? 
 
regards  
jan vestby 
 
Comment 5 Russell Coker 2005-11-13 06:27:17 EST
What is the label on /dev/hda6? 
 
In my tests SE Linux operates correctly - if the machine boots in enforcing 
mode then the init process is not permitted to read from the file handle and 
it is closed, things end there. 
 
vestby: it might be best if you compile yourself a copy of nash with my patch 
and do a test to verify that the problem is fixed. 
Comment 6 jan vestby 2005-11-20 02:30:45 EST
The patch do solve the problem. 
The problem is not related to selinux. With selinux disabled it still 
persists, only the patch removes it. 
 
 
regards  
j. vestby 
Comment 7 Russell Coker 2005-11-20 03:29:56 EST
In fact the problem isn't a serious issue when SE Linux is running.  In many 
problems of this type SE Linux causes the file handle in question to be closed 
before it can cause any problem.  Without SE Linux there is a possibility that 
the file handle will get inherited by a process that should not be permitted 
to have such access and therefore allow a security compromise. 
Comment 8 Peter Jones 2006-02-03 19:17:58 EST
Russel, are you still seeing this?

I don't see it happening on my systems, and in current nash versions all files
opened by nash itself (as opposed to libraries it uses) are marked 'close on
exec'.  So I'm going to close this and you can reopen it if you can still
reproduce this.

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