I would like to propose some kind of consolidation of tmpfs_t and tmp_t

I would like to propose some kind of consolidation of tmpfs_t and tmp_t

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

We are seeing a growing amount of bug reports on using the /tmp 
directory as a tmpfs_t file system.  Do we need to have
two separate types? Can I make the following change?
diff --exclude-from=exclude -N -u -r nsapolicy/macros/global_macros.te 
policy-1.23.4/macros/global_macros.te
--- nsapolicy/macros/global_macros.te   2005-03-24 08:58:29.000000000 -0500
+++ policy-1.23.4/macros/global_macros.te       2005-03-23 
12:36:36.000000000 -0500
@@ -418,8 +418,8 @@
 define(`tmp_domain', `
 type $1_tmp_t, file_type, sysadmfile, tmpfile $2;
 ifelse($3, `',
-`file_type_auto_trans($1_t, tmp_t, $1_tmp_t, `{ file dir }')',
-`file_type_auto_trans($1_t, tmp_t, $1_tmp_t, `$3')')
+`file_type_auto_trans($1_t, { tmpfs_t tmp_t }, $1_tmp_t, `{ file dir }')',
+`file_type_auto_trans($1_t, { tmpfs_t tmp_t }, $1_tmp_t, `$3')')
 ')

There are a few places where this conflicts such as apache where it 
calls tmpfs_domain.  But that looks
like
+`file_type_auto_trans($1_t, tmpfs_t, $1_tmpfs_t, `$3')')
Is there anything significant about this differenct.  Or can we just 
eliminate $1_tmpfs_t stuff?

Using mount -fscontext=tmp_t does not work because of other problems.


Dan

-- 



[-- Attachment #2: Re: using tmpfs for /tmp and selinux --]
[-- Type: message/rfc822, Size: 4919 bytes --]

From: Stephen Smalley <sds@tycho.nsa.gov>
To: "Fedora SELinux support list for users &amp;  developers." <fedora-selinux-list@redhat.com>
Subject: Re: using tmpfs for /tmp and selinux
Date: Thu, 24 Mar 2005 08:17:27 -0500
Message-ID: <1111670247.12486.5.camel@moss-spartans.epoch.ncsc.mil>

On Thu, 2005-03-24 at 08:43 +0100, dragoran wrote:
> doesn't seem to work:
> Mar 24 08:35:28 chello062178124144 kernel: audit(1111649728.433:0): 
> avc:  denied  { associate } for  pid=4574 exe=/usr/bin/gdm-binary 
> name=.ICE-unix scontext=user_u:object_r:tmp_t 
> tcontext=system_u:object_r:tmp_t tclass=filesystem
> Mar 24 08:35:28 chello062178124144 kernel: audit(1111649728.433:0): 
> avc:  denied  { associate } for  pid=4574 exe=/usr/bin/gdm-binary 
> name=.X11-unix scontext=user_u:object_r:tmp_t 
> tcontext=system_u:object_r:tmp_t tclass=filesystem
> Mar 24 08:35:28 chello062178124144 kernel: audit(1111649728.433:0): 
> avc:  denied  { associate } for  pid=4574 exe=/usr/bin/gdm-binary 
> name=.X11-unix scontext=user_u:object_r:tmp_t 
> tcontext=system_u:object_r:tmp_t tclass=filesystem
> Mar 24 08:35:31 chello062178124144 kernel: audit(1111649731.447:0): 
> avc:  denied  { associate } for  pid=5340 exe=/usr/X11R6/bin/Xorg 
> name=.tX0-lock scontext=user_u:object_r:tmp_t 
> tcontext=system_u:object_r:tmp_t tclass=filesystem

Ah, yes - you would need policy changes as well, e.g.
	allow tmpfile tmp_t:filesystem associate;

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-selinux-list

Re: I would like to propose some kind of consolidation of tmpfs_t and tmp_t

[Stephen Smalley]

On Thu, 2005-03-24 at 09:12 -0500, Daniel J Walsh wrote:
> We are seeing a growing amount of bug reports on using the /tmp 
> directory as a tmpfs_t file system.  Do we need to have
> two separate types? Can I make the following change?
> diff --exclude-from=exclude -N -u -r nsapolicy/macros/global_macros.te 
> policy-1.23.4/macros/global_macros.te
> --- nsapolicy/macros/global_macros.te   2005-03-24 08:58:29.000000000 -0500
> +++ policy-1.23.4/macros/global_macros.te       2005-03-23 
> 12:36:36.000000000 -0500
> @@ -418,8 +418,8 @@
>  define(`tmp_domain', `
>  type $1_tmp_t, file_type, sysadmfile, tmpfile $2;
>  ifelse($3, `',
> -`file_type_auto_trans($1_t, tmp_t, $1_tmp_t, `{ file dir }')',
> -`file_type_auto_trans($1_t, tmp_t, $1_tmp_t, `$3')')
> +`file_type_auto_trans($1_t, { tmpfs_t tmp_t }, $1_tmp_t, `{ file dir }')',
> +`file_type_auto_trans($1_t, { tmpfs_t tmp_t }, $1_tmp_t, `$3')')
>  ')
> 
> There are a few places where this conflicts such as apache where it 
> calls tmpfs_domain.  But that looks
> like
> +`file_type_auto_trans($1_t, tmpfs_t, $1_tmpfs_t, `$3')')
> Is there anything significant about this differenct.  Or can we just 
> eliminate $1_tmpfs_t stuff?
> 
> Using mount -fscontext=tmp_t does not work because of other problems.

tmpfs can be used for several different purposes, including a kernel
internal mount for shared anon mappings and System V shared memory, a
mount on /dev/shm for POSIX shared memory, a mount on /dev for udev,
optionally /tmp and /var/tmp, etc.  The original tmpfs rules were
oriented toward controlling shared memory access by a domain.  For /dev,
I think that the Fedora solution was to run restorecon from rc.sysinit
to reset the security context on the top-level /dev directory and any
nodes already created, while leaving the fscontext unmodified, whereas
others have been using a fscontext= mount for it.

For /tmp, a fscontext= mount seems to have an issue in that it is still
using type transitions for labeling inodes (including the root), so we
end up with mount_tmp_t on /tmp at least under strict policy.  Possibly
we could/should change the way that works for the root inode.  For
context= mounts, we get the desired behavior (tmp_t on /tmp and typical
derived types on files created under it), but we lose the ability to
[gs]etfilecon and setfscreatecon on /tmp presently (which we
could/should also change at least for tmpfs).  We also need a policy
change (allow tmpfile tmp_t:filesystem associate;), but that is trivial.

The concern with collapsing tmpfs_t and tmp_t together (and $1_tmpfs_t
and $1_tmp_t as well, to avoid type transition conflicts, which would
occur quite extensively with strict policy) is that it means that policy
can no longer distinguish between a domain's ability to act on /tmp
files versus its ability to act on shared memory objects (aside from the
additional controls on System V shared memory).  If everyone were using
tmpfs /tmp, that might be less of a concern, as a tmpfs file is
effectively a shared memory object too.  But if some people still want
to use a traditional /tmp, then they might care about the distinction.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I would like to propose some kind of consolidation of tmpfs_t and tmp_t

[Stephen Smalley]

On Thu, 2005-03-24 at 09:37 -0500, Stephen Smalley wrote:
> The concern with collapsing tmpfs_t and tmp_t together (and $1_tmpfs_t
> and $1_tmp_t as well, to avoid type transition conflicts, which would
> occur quite extensively with strict policy) is that it means that policy
> can no longer distinguish between a domain's ability to act on /tmp
> files versus its ability to act on shared memory objects (aside from the
> additional controls on System V shared memory).  If everyone were using
> tmpfs /tmp, that might be less of a concern, as a tmpfs file is
> effectively a shared memory object too.  But if some people still want
> to use a traditional /tmp, then they might care about the distinction.

The other point to note is that programs sometimes create /tmp files
purely for private state with no intent of sharing it with anyone else,
whereas they create shared memory objects for the purpose of sharing, so
collapsing the two together in policy would prevent such distinctions.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I would like to propose some kind of consolidation of tmpfs_t and tmp_t

[Stephen Smalley]

On Thu, 2005-03-24 at 09:37 -0500, Stephen Smalley wrote:
> For /tmp, a fscontext= mount seems to have an issue in that it is still
> using type transitions for labeling inodes (including the root), so we
> end up with mount_tmp_t on /tmp at least under strict policy.  Possibly
> we could/should change the way that works for the root inode.

Possible workaround - mount with fscontext=, then run restorecon /tmp
(not recursively, just on the top-level directory) from rc.sysinit.
That would get us tmp_t on the superblock and tmp_t on the root
directory.  Then you just need a few policy modifications like allow
tmpfile_t tmp_t:filesystem associate;, and you still can perform
[gs]etfilecon and setfscreatecon on the filesystem.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I would like to propose some kind of consolidation of tmpfs_t and tmp_t

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

Stephen Smalley wrote:

>On Thu, 2005-03-24 at 09:37 -0500, Stephen Smalley wrote:
>  
>
>>For /tmp, a fscontext= mount seems to have an issue in that it is still
>>using type transitions for labeling inodes (including the root), so we
>>end up with mount_tmp_t on /tmp at least under strict policy.  Possibly
>>we could/should change the way that works for the root inode.
>>    
>>
>
>Possible workaround - mount with fscontext=, then run restorecon /tmp
>(not recursively, just on the top-level directory) from rc.sysinit.
>That would get us tmp_t on the superblock and tmp_t on the root
>directory.  Then you just need a few policy modifications like allow
>tmpfile_t tmp_t:filesystem associate;, and you still can perform
>[gs]etfilecon and setfscreatecon on the filesystem.
>
>  
>
I don't think we have do do any of that.  It seems to work if you do a
restorecon /tmp
in the init scripts.

I am running strict policy with tmpfs mounted on /tmp

mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext3 (rw)
none on /tmp type tmpfs (rw)
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)


-- 



[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 432 bytes --]

--- initscripts-8.05/rc.d/rc.sysinit~	2005-03-24 15:02:51.000000000 -0500
+++ initscripts-8.05/rc.d/rc.sysinit	2005-03-24 15:03:11.000000000 -0500
@@ -593,6 +593,7 @@
 fi
 
 # Clean up various /tmp bits
+restorecon /tmp
 rm -f /tmp/.X*-lock /tmp/.lock.* /tmp/.gdm_socket /tmp/.s.PGSQL.*
 rm -rf /tmp/.X*-unix /tmp/.ICE-unix /tmp/.font-unix /tmp/hsperfdata_* \
        /tmp/kde-* /tmp/ksocket-* /tmp/mc-* /tmp/mcop-* /tmp/orbit-*  \

Re: I would like to propose some kind of consolidation of tmpfs_t and tmp_t

[Luke Kenneth Casson Leighton]

On Thu, Mar 24, 2005 at 12:30:58PM -0500, Stephen Smalley wrote:
> On Thu, 2005-03-24 at 09:37 -0500, Stephen Smalley wrote:
> > For /tmp, a fscontext= mount seems to have an issue in that it is still
> > using type transitions for labeling inodes (including the root), so we
> > end up with mount_tmp_t on /tmp at least under strict policy.  Possibly
> > we could/should change the way that works for the root inode.
> 
> Possible workaround - mount with fscontext=, then run restorecon /tmp
> (not recursively, just on the top-level directory) from rc.sysinit.

 i found that i had to do this for /dev on debian, when running udev.

 bearing in mind that udev on debian is NOT started from the
 initrd like wot it is in fedora, it's started from /etc/init.d
 very early on (priority 2 or 3).

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I would like to propose some kind of consolidation of tmpfs_t and tmp_t

[Stephen Smalley]

On Thu, 2005-03-24 at 15:06 -0500, Daniel J Walsh wrote:
> I don't think we have do do any of that.  It seems to work if you do a
> restorecon /tmp
> in the init scripts.
> 
> I am running strict policy with tmpfs mounted on /tmp

Yes, that works as long as you have:
	allow tmpfile tmpfs_t:filesystem associate;

Right?

-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: I would like to propose some kind of consolidation of tmpfs_t and tmp_t

[Daniel J Walsh]

Stephen Smalley wrote:

>On Thu, 2005-03-24 at 15:06 -0500, Daniel J Walsh wrote:
>  
>
>>I don't think we have do do any of that.  It seems to work if you do a
>>restorecon /tmp
>>in the init scripts.
>>
>>I am running strict policy with tmpfs mounted on /tmp
>>    
>>
>
>Yes, that works as long as you have:
>	allow tmpfile tmpfs_t:filesystem associate;
>
>Right?
>
>  
>
I have added that, so I am not sure if it is necessary, but with it is 
working with the change.

Dan

-- 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.