Bug 172355 - nash resume leaves a file handle to the swap device open
Summary: nash resume leaves a file handle to the swap device open
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-03 09:44 UTC by Russell Coker
Modified: 2007-11-30 22:11 UTC (History)
0 users

Clone Of:
Last Closed: 2006-02-04 00:17:58 UTC

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

Description Russell Coker 2005-11-03 09:44:05 UTC
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):

How reproducible:

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

Additional info:

Comment 1 Russell Coker 2005-11-03 09:57:15 UTC
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-07 00:35:11 UTC
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 

Comment 3 Russell Coker 2005-11-07 02:15:52 UTC
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 22:36:10 UTC
system is current rawhide (as far as yum will take it): 
# getenforce 
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 ? 
jan vestby 

Comment 5 Russell Coker 2005-11-13 11:27:17 UTC
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 07:30:45 UTC
The patch do solve the problem. 
The problem is not related to selinux. With selinux disabled it still 
persists, only the patch removes it. 
j. vestby 

Comment 7 Russell Coker 2005-11-20 08:29:56 UTC
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-04 00:17:58 UTC
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.