Bug 238871

Summary:	SE-Linux prevents loopback mounting of a jffs2 image in permissive mode
Product:	[Fedora] Fedora	Reporter:	John (J5) Palmieri <johnp>
Component:	kernel	Assignee:	Eric Paris <eparis>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6	CC:	dwalsh, eparis, jkeck, kmacmill, sdsmall
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	F8	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-11-09 15:49:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description John (J5) Palmieri 2007-05-03 15:49:58 UTC

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 17:34:02 UTC

Any AVC or other selinux messages in /var/log/messages or /var/log/audit/audit.log?

Comment 2 John (J5) Palmieri 2007-05-04 18:24:57 UTC

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 18:25:51 UTC

Note the line

modprobe blockmtd

should read

modprobe mtdblock

Comment 4 Karl MacMillan 2007-05-04 18:38:05 UTC

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 18:55:21 UTC

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 11:31:34 UTC

But shouldn't it just work in Permissive mode?

Comment 7 Stephen Smalley 2007-05-07 11:58:20 UTC

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 17:48:53 UTC

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 15:49:42 UTC

F7 and F8 have these set.  closing as current release.