Bug 448439 - Encrypted /tmp partition gets wrong security context
Summary: Encrypted /tmp partition gets wrong security context
Status: CLOSED DUPLICATE of bug 238437
Alias: None
Product: Fedora
Classification: Fedora
Component: upstart   
(Show other bugs)
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Casey Dahlin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-26 21:33 UTC by Joachim Katzer
Modified: 2014-06-18 08:46 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-30 14:35:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Script called by incrontab to fix security context after mounting /tmp (1.01 KB, text/plain)
2008-06-02 21:45 UTC, Joachim Katzer
no flags Details

Description Joachim Katzer 2008-05-26 21:33:36 UTC
Description of problem:

When using an encrypted /tmp partition, its security context is set not correct
during boot. As a consequence, after login to xguest desktop does not start.


Version-Release number of selected component (if applicable):
selinux-policy-3.3.1-51.fc9.noarch
selinux-policy-targeted-3.3.1-51.fc9.noarch



How reproducible:

System: Fedora9 with XFCE desktop and xguest package installed


Steps to Reproduce:
1. Configure encrypted /tmp partition (e.g. on LV tmp in VG system):
   Add to /etc/crypttab: 
   "ctmp	/dev/system/tmp		/dev/urandom	tmp,cipher=aes-cbc-essiv:sha256"
 
   Append to /etc/fstab:
   "/dev/mapper/ctmp   /tmp  ext2  noexec     0 0"
  
2. Reboot 
3. Call ls -laZ /tmp
  
Actual results:
  drwxrwxrwt  root root system_u:object_r:file_t:s0      .

  This apparently has some (side)-effects: 
  Sporadically black background of gdm
  After login to xguest (XFCE) desktop does not start
  Lots of avc errors like: 

type=AVC msg=audit(1211836232.842:911): avc:  denied  { write } for  pid=3229
comm="gconfd-2" name="/" dev=dm-8 ino=2
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=system_u:object_r:file_t:s0 tclass=dir


Expected results:
  drwxrwxrwt  root root system_u:object_r:tmp_t:s0      .


Additional info:
  After calling "restorecon -r /tmp" login to xguest works.

Comment 1 Daniel Walsh 2008-05-27 18:58:08 UTC
What actually creates the file system?

Not sure the best way to fix this.

Comment 2 Joachim Katzer 2008-05-28 19:27:53 UTC
What actually creates the file system?
# ls -laZ /tmp
drwxrwxrwt  root root system_u:object_r:file_t:s0      .
drwxr-xr-x  root root system_u:object_r:root_t:s0      ..
drwx------  joachim users unconfined_u:object_r:file_t:s0  gconfd-joachim
drwxrwxrwt  joachim users unconfined_u:object_r:file_t:s0  .ICE-unix
drwx------  joachim users unconfined_u:object_r:file_t:s0  keyring-SLt0Rd
drwx------  root root system_u:object_r:file_t:s0      lost+found
,,,

# grep '^/' /etc/mtab
/dev/mapper/system-fedora / ext3 rw 0 0
/tmp /tmp none rw,bind 0 0
/dev/mapper/ctmp /tmp ext2 rw,noexec 0 0
...

Note: since /tmp is encrypted by a random key, its ext2 filesystem is created
when it is mounted after boot.

I have found a simple workaround to get xguest working again: I've added the
following command to /etc/rc.local:
at now + 1 minutes << END
/sbin/restorecon -r /tmp
END

The direct call of restorecon in /etc/rc.local does not work and lets the mount
of encrypted /tmp partition fail. Therefore I guess it's not a problem of the
selinux policy but of the upstart process.

In Fedora 8 the same configuration had worked fine. The problem appeared after
the upgrade to Fedora 9.




Comment 3 Daniel Walsh 2008-05-28 20:23:22 UTC
Could you add a mount command to the rc.local to see what is mounted when you
run the restorecon command?

This is not an SELinux bug, I am reassigning to upstart for now.



Comment 4 Joachim Katzer 2008-05-29 20:13:02 UTC
(In reply to comment #3)
> Could you add a mount command to the rc.local to see what is mounted when you
> run the restorecon command?
> 
*** I've added the following commands to rc.local:
logger -t 'mounted when calling rc.local' `mount`
logger -t 'security context of tmp partition' `ls -ldZ /tmp`

*** This is the result. At this point, the crypto volume /dev/system/ctmp is
apparently not mounted:
May 29 20:58:36 machtnix mounted when calling rc.local:
/dev/mapper/system-fedora on / type ext3 (rw) proc on /proc type proc (rw) sysfs
on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs
on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw) /tmp on /tmp type none (rw,bind) /var/tmp on /var/tmp type none (rw,bind)
/home/xguest on /home/xguest type none (rw,bind) sunrpc on
/var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) fusectl on /sys/fs/fuse/connections
type fusectl (rw)
May 29 20:58:36 machtnix security context of tmp partition: drwxrwxrwt root root
system_u:object_r:tmp_t:s0 /tmp
May 29 20:58:36 machtnix setroubleshoot: SELinux prevented mount from mounting
on the file or directory "/tmp/sh-thd-1212058248" (type "initrc_tmp_t"). For
complete SELinux messages. run sealert -l b0ac6a1c-c998-41d9-932a-c40f9f690ee6
May 29 20:58:36 machtnix NetworkManager: <info>  starting...


*** The Raw Audit Messages of the AVC error are:
host=machtnix type=AVC msg=audit(1212087516.123:10): avc:  denied  { write } for
 pid=2468 comm="mount" path="/tmp/sh-thd-1212058248" dev=dm-3 ino=229384
scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0
tclass=file

host=machtnix type=SYSCALL msg=audit(1212087516.123:10): arch=40000003
syscall=11 success=yes exit=0 a0=9972ed0 a1=9972e40 a2=9972908 a3=0 items=0
ppid=2467 pid=2468 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mount" exe="/bin/mount"
subj=system_u:system_r:mount_t:s0 key=(null)

sealert gives the advice to fix the problem by command: 
  setsebool -P allow_mount_anyfile=1

But this has no effect for the reported problem (it just prevents the logged AVC
error).


Comment 5 Daniel Walsh 2008-05-30 12:44:08 UTC
So this looks like rc.local is not the final thing that upstart does.  The
question is whether assuming /etc/rc.local is run after the entire init process
is complete is a correct assumption.

Comment 6 Bill Nottingham 2008-05-30 14:35:42 UTC

*** This bug has been marked as a duplicate of 238437 ***

Comment 7 Joachim Katzer 2008-06-02 21:45:35 UTC
Created attachment 308015 [details]
Script called by incrontab to fix security context after mounting /tmp 

Script is intended only as a means to analyze the problem cause and as a quick
workaround.

Comment 8 Joachim Katzer 2008-06-02 21:46:47 UTC
(In reply to comment #6)
> 
> *** This bug has been marked as a duplicate of 238437 ***

I don't agree this problem is a duplicate of bug 238437. 

The encrypted /tmp partition is actually mounted on Fedora9, though not at the
time when rc.local is called, but about 10 seconds later after finishing
Network(Manager) initializations and before gdm is started. As mentioned in
238437, this seems to me the correct behaviour because init/upstart has to wait
for RNG initialization. The only problem on my system is that the /tmp directory
gets the wrong security context after mounting - causing problems with the new
gdm and xguest. 

I've written a modified workaround using incrontab (the idea is to call a
callback script "on_mount" after each mount and umount):

incrontab entry:
/etc/mtab IN_CLOSE_WRITE /usr/local/bin/on_mount

When the encrypted tmp partition /dev/mapper/ctmp is mounted, my script calls
logs the new mount entry, the current security context of the /tmp dir and then
restorecon to fix the security context:

Jun  2 22:59:29 machtnix mount called by rc.local: /dev/mapper/system-fedora /
ext3 rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts
devpts rw,gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs rw 0 0 none
/proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 /tmp /tmp none rw,bind 0 0 /var/tmp
/var/tmp none rw,bind 0 0 /home/xguest /home/xguest none rw,bind 0 0 sunrpc
/var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 fusectl /sys/fs/fuse/connections
fusectl rw 0 0
Jun  2 22:59:29 machtnix security context of tmp partition: drwxrwxrwt root root
system_u:object_r:tmp_t:s0 /tmp
...
Jun  2 22:59:38 machtnix NetworkManager: <info>  Activation (eth1) Stage 5 of 5
(IP Configure Commit) complete.
Jun  2 22:59:38 machtnix mounted: > /dev/mapper/ctmp /tmp ext2 rw,noexec 0 0
Jun  2 22:59:39 machtnix /tmp context: drwxrwxrwt root root
system_u:object_r:file_t:s0 . drwxr-xr-x root root system_u:object_r:root_t:s0
.. drwx------ root root system_u:object_r:file_t:s0 lost+found
Jun  2 22:59:39 machtnix after restorecon: drwxrwxrwt root root
system_u:object_r:tmp_t:s0 . drwxr-xr-x root root system_u:object_r:root_t:s0 ..
drwx------ root root system_u:object_r:lost_found_t:s0 lost+found
Jun  2 22:59:40 machtnix gconfd (gdm-2640): (Version 2.22.0) wird gestartet,
Prozesskennung 2640, Benutzer »gdm«







Comment 9 Eric Paris 2008-06-02 22:20:39 UTC
Ok, I tend to agree that you did hit the other bug in question but this isn't
really a dupe.  The issue is that tmpfs has full support for extended
attributes.  With 'normal' filesystems when anaconda creates them anaconda gives
the root inode the correct selinux label for whereever it is going to be
mounted.  And say if you later create your own persistent fs that fs is going to
have 'file_t' until you mount it and label it the first time.

In this case since you can't save a persistant label for tmpfs all of the above
fails.  My suggestion would be to add

rootcontext=system_u:object_r:tmp_t:s0

in /etc/fstab.  Since you are creating this FS every time you need to label it
every time.  Admittedly I haven't tried this under an encrypted tmpfs, but this
is needed to get proper labeling with a non-encrypted tmpfs mounted on /tmp....

Comment 10 Joachim Katzer 2008-06-03 17:20:48 UTC
(In reply to comment #9)

> My suggestion would be to add
> 
> rootcontext=system_u:object_r:tmp_t:s0
> 
> in /etc/fstab.  
Thanks for your helpful explanation. I've followed the advice and it works fine.
I think, your suggestion is the final solution to my reported problem. 




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