Bug 238871 - SE-Linux prevents loopback mounting of a jffs2 image in permissive mode
SE-Linux prevents loopback mounting of a jffs2 image in permissive mode
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-03 11:49 EDT by John (J5) Palmieri
Modified: 2013-03-13 00:51 EDT (History)
5 users (show)

See Also:
Fixed In Version: F8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-09 10:49:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John (J5) Palmieri 2007-05-03 11:49:58 EDT
Description of problem:

I need to be able to mount jffs2 disk images however doing so causes issues with
SE-Linix even if in permissive mode.  Sending -o 
context=system_u:object_r:nfs_t to mount allows me to mount the drive.

I am not sure if this is an issue with mount, the kernel drivers or se-linux
itself but Dan seemed to have some understanding of the issue so I'm starting here. 

How reproducible:

Always



Download a jffs2 image from
http://olpc.download.redhat.com/olpc/streams/development/LATEST/jffs2/

Steps to Reproduce:

run these commands:

modprobe loop
modprobe blockmtd
losetup /dev/loop0 /path/to/img
modprobe block2mtd block2mtd=/dev/loop0,128ki
mount /dev/mtdblock0 /mnt/path

#this should produce an error
mount -tjffs2 /dev/mtdblock0 /mnt/test

#this should succeed
mount -tjffs2 -o context=system_u:object_r:nfs_t /dev/mtdblock0 /mnt/test
  
Actual results:

image fails to mount

Expected results:

image mounts (disk should be at %100 usage so don't worry if you can't write to it)
Comment 1 Karl MacMillan 2007-05-04 13:34:02 EDT
Any AVC or other selinux messages in /var/log/messages or /var/log/audit/audit.log?
Comment 2 John (J5) Palmieri 2007-05-04 14:24:57 EDT
From /var/log/messages (audit.log doesn't log anything relevant)

May  4 14:25:30 localhost kernel: block2mtd: mtd0: [d: /dev/loop0] erase_size =
128KiB [131072]
May  4 14:25:30 localhost kernel: block2mtd: version $Revision: 1.30 $
May  4 14:25:30 localhost kernel: block2mtd: Overrun end of disk in cache readahead
May  4 14:25:30 localhost kernel:
May  4 14:25:30 localhost kernel: block2mtd: Overrun end of disk in cache readahead
May  4 14:25:30 localhost kernel:
May  4 14:25:30 localhost kernel: block2mtd: Overrun end of disk in cache readahead
May  4 14:25:30 localhost kernel:
May  4 14:25:36 localhost kernel: JFFS2 version 2.2. (NAND) (SUMMARY)  (C)
2001-2006 Red Hat, Inc.
May  4 14:25:51 localhost kernel: SELinux: (dev jffs2, type jffs2) has no xattr
support
Comment 3 John (J5) Palmieri 2007-05-04 14:25:51 EDT
Note the line

modprobe blockmtd

should read

modprobe mtdblock
Comment 4 Karl MacMillan 2007-05-04 14:38:05 EDT
I get an error earlier on RHEL 5 - the command "modprobe block2mtd
block2mtd=/dev/loop0,128ki" seems to fail and dmesg shows:

block2mtd: error: cannot open device dev/loop0
block2mtd: version $Revision: 1.30 $

I also get the denial:

#============= mount_t ==============
# src="mount_t" tgt="unlabeled_t" class="filesystem", perms="mount"
# comm="mount" exe="" path=""
allow mount_t unlabeled_t:filesystem mount;
Comment 5 Stephen Smalley 2007-05-04 14:55:21 EDT
jffs2 now supports xattrs, so the policy is configured to expect them to be enabled.
JFFS2_FS_XATTR=y
JFFS2_FS_SECURITY=y

Comment 6 Daniel Walsh 2007-05-05 07:31:34 EDT
But shouldn't it just work in Permissive mode?
Comment 7 Stephen Smalley 2007-05-07 07:58:20 EDT
Permissive mode was only intended to address permission denials, not all classes
of errors.  This is a mismatch between the policy configuration for filesystem
labeling behavior for jffs2 and kernel configuration.  As a result, we can't
even determine a security label for the root inode of the filesystem at mount
time.  We could leave it unlabeled and allow the mount to proceed, in which case
it would show up as unlabeled_t accesses upon subsequent access, but it seems
preferable to catch it early.  Things like setroubleshoot or audit2allow
wouldn't catch or recognize the original issue, as it isn't an avc denial.
Comment 8 Daniel Walsh 2007-05-07 13:48:53 EDT
Ok so this is a bug in the way the kernel is being built?  So I am reassigning
to kernel and eparis.
Comment 9 Eric Paris 2007-11-09 10:49:42 EST
F7 and F8 have these set.  closing as current release.

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