From mboxrd@z Thu Jan 1 00:00:00 1970 From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Mon, 17 Jan 2011 09:07:27 -0500 Subject: [refpolicy] two fixups for mount_t: uses mount.tmpfs and manage lock files In-Reply-To: References: , , <4D2B134E.8010502@tresys.com>, Message-ID: <4D344D1F.4080206@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 1/17/2011 6:06 AM, HarryCiao wrote: > Hi Chirs, > > I have tried to come up with the attached patches to label > /sbin/mount.tmpfs as mount_helper_exec_t, and call corecmd_exec_shell() > for the mount_helper_t domain rather than the mount_t domain. > > But soon I found I could not enforce the domain transition from mount_t > to mount_helper_t, just since the /sbin/mount.tmpfs is a shell script, > and the child process forked by mount program would always try to > execute the bash program in order to run the shell script: > > root at qemu-host:/root> mount -t tmpfs none tmp/ > type=1400 audit(1294827015.929:14): avc: denied { execute } for pid=607 > comm="mount" name="bash" dev=sda ino=24596 > scontext=root:sysadm_r:mount_t:s0-s15:c0.c1023 > tcontext=system_u:object_r:shell_exec_t:s0 tclass=file > root at qemu-host:/root> > > So it seems there is no way to enforce the domain transition from > mount_t into mount_helper_t BEFORE executing the bash, unless we use > dyntransition and setcurrent permissions to mount_t, but this would > require we change mount source code to add calls to setcon() and these > two permissions are recommended never to be used for breaking label > tranquility. > > Any other ideas? Looks like we'll have to go with your original patch. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com