[redhat-lspp] Idenifying Removable Media

[Debora Velarde]

redhat-lspp-bounces at redhat.com wrote on 10/05/2005 10:26:24 AM:

> On Wed, 2005-10-05 at 10:58 -0400, Steve Grubb wrote:
> > A question came up. When media is inserted, there are 3 
> possibilities if its 
> > ext3 partition. It could be a plain ext3 partition from a RHEL3 
machine, it 
> > could have some SE Linux information from FC3/4, or it could have MLS 
> > information.
> > 
> > How do we identify the media and treat it appropriately so that 
> its not seen 
> > as corrupted by the native machine when the media is returned? From a 
LSPP 
> > perspective, should extended attributes not be written to plain ext3 
> > partition? How would someone check it?
> > 
> > This same issue comes up on dual boot machines.
> 
> For exchanging between non-SELinux and SELinux systems, any selinux
> attribute written to the media while it is mounted on the SELinux system
> should just be ignored when it is mounted on the non-SELinux system.
> There was an xattr-on-symlinks compatibility issue a long time ago for
> 2.4 kernels, but that was fixed.
> 
> For exchanging between non-MLS SELinux and MLS SELinux systems, there is
> presently an issue, since any files created while the media is mounted
> on the MLS SELinux system will get an extended attribute value with a
> MLS level in it, which will not be valid on the non-MLS SELinux system.
> 
> (Side bar:  Such media should likely always be mounted on the MLS
> SELinux system with a context mount option to explicitly set the level,
> although it will work without one due to the defaulting logic introduced
> by James in 2.6.13.  That would prevent setxattr on the media from
> occurring.  But it appears that it wouldn't prevent new files from
> having their extended attribute set by the fs code - looks like we would
> need to adjust inode_init_security to _not_ return the (name,context)
> pair for mountpoint labeled filesystem to avoid that.  Thoughts?  If we
> made that change, then we could just use context mounts for removable
> media and avoid any problems with exchange there.  It would still be an
> issue for dual boots.)
> 
> "Plain ext3 partition" seems a bit misleading, as there is no
> fundamental difference.  Just the presence or absence of security xattrs
> (SELinux vs. non-SELinux), and just the presence or absence of a MLS
> level in the xattr values (MLS SELinux vs. non-MLS SELinux).  SELinux
> does get the xattr of the root directory when the filesystem is mounted,
> so it can detect those states at that time.  But I don't think you want
> SELinux automatically disabling setxattr and new file labeling just
> because the partition wasn't labeled originally; that used to be the
> norm for installing SELinux on a pre-existing non-SELinux system.
> Likewise for non-MLS to MLS (or MCS) upgrade.
> 
> I suspect that we need to make a change to the non-MLS case to make it
> forgiving of the presence of the MLS level (i.e. ignore it) and back
> port that as needed for the dual boot case, so that a FC4/RHEL4 instance
> can access files created while running a FC5/RHEL5 instance. 
> 
> -- 
> Stephen Smalley
> National Security Agency
> 
> --
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp

I've been working on adding xattr support to zip and unzip.  I have a 
question about what the correct behavior should be when you zip up a file 
on an MLS system and then unzip it on a non-MLS system.  Right now, when I 
run unzip on the non-MLS system, my call to setxattr fails because of the 
MLS level.  Should the right behavior be:
1. Delete the unzipped files if the xattr could not be successfully set. 
Then report an error that it was not successfully unzipped because of an 
xattr problem.
2. Go ahead and extract all the files.  But report a warning that the 
extended attributes were not successfully set?
3. If the setxattr fails when trying to set "security.selinux", should I 
then try to remove the MLS level from the value and attempt to set that?

Thanks,
debbie