1. Since the mount program would make use of the shell script of mount.tmpfs
to preserve the mountpoint's security context across mounting if it ever
makes sense, the mount domain should have been able to execute the shell
and rw its fifo files.
type=1400 audit(1292851031.156:19): avc: denied { execute } for pid=513 comm="mount" name="bash" dev=sda ino=98324 scontext=system_u:system_r:mount_t:s0-s15:c0.c1023 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=1400 audit(1288069794.081:6): avc: denied { getattr } for pid=92 comm="mount.tmpfs" path="pipe:[2444]" dev=pipefs ino=2444 scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t tclass=fifo_file
type=1400 audit(1288069794.085:7): avc: denied { write } for pid=92 comm="mount.tmpfs" path="pipe:[2444]" dev=pipefs ino=2444 scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t tclass=fifo_file
type=1400 audit(1288069794.149:8): avc: denied { read } for pid=93 comm="grep" path="pipe:[2444]" dev=pipefs ino=2444 scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t tclass=fifo_file
type=1400 audit(1288069794.225:9): avc: denied { ioctl } for pid=95 comm="ls" path="pipe:[2446]" dev=pipefs ino=2446 scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t tclass=fifo_file
2. While the mount program writes into /etc/mtab, it needs to create
a lock file under /var/lock/, otherwise the /etc/mtab would be empty.
type=1400 audit(1287984885.601:19): avc: denied { write } for pid=471 comm="mount" name="lock" dev=sda ino=114693 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:var_lock_t tclass=dir
can't create lock file /var/lock/mtab~471: Permission denied (use -n flag to override)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101221/958c011d/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mount_t-uses-tmpfs-helper.patch
Type: application/octet-stream
Size: 2551 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101221/958c011d/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-mount_t-manage-lock-files.patch
Type: application/octet-stream
Size: 1290 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101221/958c011d/attachment-0001.obj
On 12/20/10 22:16, HarryCiao wrote:
> 1. Since the mount program would make use of the shell script of mount.tmpfs
> to preserve the mountpoint's security context across mounting if it ever
> makes sense, the mount domain should have been able to execute the shell
> and rw its fifo files.
>
> type=1400 audit(1292851031.156:19): avc: denied { execute } for pid=513
> comm="mount" name="bash" dev=sda ino=98324
> scontext=system_u:system_r:mount_t:s0-s15:c0.c1023
> tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
> type=1400 audit(1288069794.081:6): avc: denied { getattr } for pid=92
> comm="mount.tmpfs" path="pipe:[2444]" dev=pipefs ino=2444
> scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> tclass=fifo_file
> type=1400 audit(1288069794.085:7): avc: denied { write } for pid=92
> comm="mount.tmpfs" path="pipe:[2444]" dev=pipefs ino=2444
> scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> tclass=fifo_file
> type=1400 audit(1288069794.149:8): avc: denied { read } for pid=93
> comm="grep" path="pipe:[2444]" dev=pipefs ino=2444
> scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> tclass=fifo_file
> type=1400 audit(1288069794.225:9): avc: denied { ioctl } for pid=95
> comm="ls" path="pipe:[2446]" dev=pipefs ino=2446
> scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> tclass=fifo_file
This makes me wonder if we should make a mount_helper_exec_t for these
mount.* helper programs. I'd rather not allow mount to execute
shell_exec_t.
> 2. While the mount program writes into /etc/mtab, it needs to create
> a lock file under /var/lock/, otherwise the /etc/mtab would be empty.
>
> type=1400 audit(1287984885.601:19): avc: denied { write } for pid=471
> comm="mount" name="lock" dev=sda ino=114693
> scontext=system_u:system_r:mount_t tcontext=system_u:object_r:var_lock_t
> tclass=dir
> can't create lock file /var/lock/mtab~471: Permission denied (use -n
> flag to override)
Which distro is this on?
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
> Date: Mon, 10 Jan 2011 09:10:22 -0500
> From: cpebenito at tresys.com
> To: harrytaurus2002 at hotmail.com
> CC: refpolicy at oss.tresys.com
> Subject: Re: two fixups for mount_t: uses mount.tmpfs and manage lock files
>
> On 12/20/10 22:16, HarryCiao wrote:
> > 1. Since the mount program would make use of the shell script of mount.tmpfs
> > to preserve the mountpoint's security context across mounting if it ever
> > makes sense, the mount domain should have been able to execute the shell
> > and rw its fifo files.
> >
> > type=1400 audit(1292851031.156:19): avc: denied { execute } for pid=513
> > comm="mount" name="bash" dev=sda ino=98324
> > scontext=system_u:system_r:mount_t:s0-s15:c0.c1023
> > tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
> > type=1400 audit(1288069794.081:6): avc: denied { getattr } for pid=92
> > comm="mount.tmpfs" path="pipe:[2444]" dev=pipefs ino=2444
> > scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> > tclass=fifo_file
> > type=1400 audit(1288069794.085:7): avc: denied { write } for pid=92
> > comm="mount.tmpfs" path="pipe:[2444]" dev=pipefs ino=2444
> > scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> > tclass=fifo_file
> > type=1400 audit(1288069794.149:8): avc: denied { read } for pid=93
> > comm="grep" path="pipe:[2444]" dev=pipefs ino=2444
> > scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> > tclass=fifo_file
> > type=1400 audit(1288069794.225:9): avc: denied { ioctl } for pid=95
> > comm="ls" path="pipe:[2446]" dev=pipefs ino=2446
> > scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> > tclass=fifo_file
>
> This makes me wonder if we should make a mount_helper_exec_t for these
> mount.* helper programs. I'd rather not allow mount to execute
> shell_exec_t.
>
Good idea!
I will work on this issue later.
> > 2. While the mount program writes into /etc/mtab, it needs to create
> > a lock file under /var/lock/, otherwise the /etc/mtab would be empty.
> >
> > type=1400 audit(1287984885.601:19): avc: denied { write } for pid=471
> > comm="mount" name="lock" dev=sda ino=114693
> > scontext=system_u:system_r:mount_t tcontext=system_u:object_r:var_lock_t
> > tclass=dir
> > can't create lock file /var/lock/mtab~471: Permission denied (use -n
> > flag to override)
>
> Which distro is this on?
>
Well, the mount program comes from util-linux-2.13.1-6.fc9.
Best regards,
Harry
> --
> Chris PeBenito
> Tresys Technology, LLC
> http://www.tresys.com | oss.tresys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110111/88fb9d00/attachment.html
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?
Best regards,
Harry
From: [email protected]
To: cpebenito at tresys.com
Date: Tue, 11 Jan 2011 03:46:11 +0000
CC: refpolicy at oss.tresys.com
Subject: Re: [refpolicy] two fixups for mount_t: uses mount.tmpfs and manage lock files
> Date: Mon, 10 Jan 2011 09:10:22 -0500
> From: cpebenito at tresys.com
> To: harrytaurus2002 at hotmail.com
> CC: refpolicy at oss.tresys.com
> Subject: Re: two fixups for mount_t: uses mount.tmpfs and manage lock files
>
> On 12/20/10 22:16, HarryCiao wrote:
> > 1. Since the mount program would make use of the shell script of mount.tmpfs
> > to preserve the mountpoint's security context across mounting if it ever
> > makes sense, the mount domain should have been able to execute the shell
> > and rw its fifo files.
> >
> > type=1400 audit(1292851031.156:19): avc: denied { execute } for pid=513
> > comm="mount" name="bash" dev=sda ino=98324
> > scontext=system_u:system_r:mount_t:s0-s15:c0.c1023
> > tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
> > type=1400 audit(1288069794.081:6): avc: denied { getattr } for pid=92
> > comm="mo
unt.tmpfs" path="pipe:[2444]" dev=pipefs ino=2444
> > scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> > tclass=fifo_file
> > type=1400 audit(1288069794.085:7): avc: denied { write } for pid=92
> > comm="mount.tmpfs" path="pipe:[2444]" dev=pipefs ino=2444
> > scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> > tclass=fifo_file
> > type=1400 audit(1288069794.149:8): avc: denied { read } for pid=93
> > comm="grep" path="pipe:[2444]" dev=pipefs ino=2444
> > scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> > tclass=fifo_file
> > type=1400 audit(1288069794.225:9): avc: denied { ioctl } for pid=95
> > comm="ls" path="pipe:[2446]" dev=pipefs ino=2446
> > scontext=system_u:system_r:mount_t tcontext=system_u:system_r:mount_t
> > tclass=fifo_file
>
> This makes me wonder if we shou
ld make a mount_helper_exec_t for these
> mount.* helper programs. I'd rather not allow mount to execute
> shell_exec_t.
>
Good idea!
I will work on this issue later.
> > 2. While the mount program writes into /etc/mtab, it needs to create
> > a lock file under /var/lock/, otherwise the /etc/mtab would be empty.
> >
> > type=1400 audit(1287984885.601:19): avc: denied { write } for pid=471
> > comm="mount" name="lock" dev=sda ino=114693
> > scontext=system_u:system_r:mount_t tcontext=system_u:object_r:var_lock_t
> > tclass=dir
> > can't create lock file /var/lock/mtab~471: Permission denied (use -n
> > flag to override)
>
> Which distro is this on?
>
Well, the mount program comes from util-linux-2.13.1-6.fc9.
Best regards,
Harry
> --
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys
.com | oss.tresys.com
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110117/34e5e356/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-mount_helper_t-domain-to-run-the-shell-script-of.patch
Type: text/x-patch
Size: 2150 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110117/34e5e356/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-the-interface-of-mount_domtrans_mount_helper.patch
Type: text/x-patch
Size: 1226 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110117/34e5e356/attachment-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Make-mount_t-domain-able-to-transition-into-mount_he.patch
Type: text/x-patch
Size: 1345 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110117/34e5e356/attachment-0002.bin
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
http://www.tresys.com | oss.tresys.com