fs_use_trans

fs_use_trans

[William Roberts]

The docs for fs_use_trans state:

The fs_use_trans statement is used to allocate a security context to
pseudo filesystems such as pseudo terminals and temporary objects. The
assigned context is derived from the creating process and that of the
filesystem type based on transition rules.


Can someone give me an example? For instance if I had:

fs_use_trans devpts u:object_r:devpts:s0;

and a daemon running with context:
u:r:init:s0

and it creates something on the devpts, what is the resulting context
of the object?

Thanks,
Bill

Re: fs_use_trans

[Stephen Smalley]

On 10/10/2014 07:05 PM, William Roberts wrote:
> The docs for fs_use_trans state:
> 
> The fs_use_trans statement is used to allocate a security context to
> pseudo filesystems such as pseudo terminals and temporary objects. The
> assigned context is derived from the creating process and that of the
> filesystem type based on transition rules.
> 
> 
> Can someone give me an example? For instance if I had:
> 
> fs_use_trans devpts u:object_r:devpts:s0;
> 
> and a daemon running with context:
> u:r:init:s0
> 
> and it creates something on the devpts, what is the resulting context
> of the object?

It depends on whether you have a type_transition rule defined in policy.
For example, in the Android policy, we have the create_pty() macro
defined in te_macros, and if you had create_pty(init) in your policy,
then it would set up a type transition so that any pty created by init
would be labeled with a init_devpts type rather than just devpts.

Re: fs_use_trans

[William Roberts]

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

Yeah looking at this statement doesn't really just allow for the use of
type_transition statements on that filesystem? It doesn't actually generate
labels, you still need the typetrans rule. It appears that the definition
is overreaching for its actual function and probably inferring something
from refpolicy.
On Oct 14, 2014 7:48 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:

> On 10/10/2014 07:05 PM, William Roberts wrote:
> > The docs for fs_use_trans state:
> >
> > The fs_use_trans statement is used to allocate a security context to
> > pseudo filesystems such as pseudo terminals and temporary objects. The
> > assigned context is derived from the creating process and that of the
> > filesystem type based on transition rules.
> >
> >
> > Can someone give me an example? For instance if I had:
> >
> > fs_use_trans devpts u:object_r:devpts:s0;
> >
> > and a daemon running with context:
> > u:r:init:s0
> >
> > and it creates something on the devpts, what is the resulting context
> > of the object?
>
> It depends on whether you have a type_transition rule defined in policy.
> For example, in the Android policy, we have the create_pty() macro
> defined in te_macros, and if you had create_pty(init) in your policy,
> then it would set up a type transition so that any pty created by init
> would be labeled with a init_devpts type rather than just devpts.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1765 bytes --]

Re: fs_use_trans

[Stephen Smalley]

On 10/14/2014 11:00 AM, William Roberts wrote:
> Yeah looking at this statement doesn't really just allow for the use of
> type_transition statements on that filesystem? It doesn't actually generate
> labels, you still need the typetrans rule. It appears that the definition
> is overreaching for its actual function and probably inferring something
> from refpolicy.

Each of the fs_use_* statements specifies how to determine the label for
existing inodes in the filesystem.  fs_use_xattr tells SELinux to fetch
the inode label via ->getxattr().  fs_use_task tells SELinux to assign
the inode the label of its creator.  fs_use_trans tells SELinux to
compute the inode label based on the result of security_transition_sid()
on the creating process SID and the filesystem SID.  What
security_transition_sid() returns depends on whether or not you have a
transition rule in policy.  So fs_use_trans doesn't guarantee that you
have a transition rule in place; it just allows you to use transition
rules if you wish to label the inodes based on some combination of the
creating process domain and the filesystem type.

Re: fs_use_trans

[William Roberts]

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

On Oct 14, 2014 10:43 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
>
> On 10/14/2014 11:00 AM, William Roberts wrote:
> > Yeah looking at this statement doesn't really just allow for the use of
> > type_transition statements on that filesystem? It doesn't actually
generate
> > labels, you still need the typetrans rule. It appears that the
definition
> > is overreaching for its actual function and probably inferring something
> > from refpolicy.
>
> Each of the fs_use_* statements specifies how to determine the label for
> existing inodes in the filesystem.  fs_use_xattr tells SELinux to fetch
> the inode label via ->getxattr().  fs_use_task tells SELinux to assign
> the inode the label of its creator.  fs_use_trans tells SELinux to
> compute the inode label based on the result of security_transition_sid()
> on the creating process SID and the filesystem SID.  What
> security_transition_sid() returns depends on whether or not you have a
> transition rule in policy.  So fs_use_trans doesn't guarantee that you
> have a transition rule in place; it just allows you to use transition
> rules if you wish to label the inodes based on some combination of the
> creating process domain and the filesystem type.
>
>
OK that makes more sense to me than the other documents I read. Thanks.

[-- Attachment #2: Type: text/html, Size: 1592 bytes --]

Re: fs_use_trans

[Dominick Grift]

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

On Tue, Oct 14, 2014 at 01:39:39PM -0400, Stephen Smalley wrote:
> On 10/14/2014 11:00 AM, William Roberts wrote:
> > Yeah looking at this statement doesn't really just allow for the use of
> > type_transition statements on that filesystem? It doesn't actually generate
> > labels, you still need the typetrans rule. It appears that the definition
> > is overreaching for its actual function and probably inferring something
> > from refpolicy.
> 
> Each of the fs_use_* statements specifies how to determine the label for
> existing inodes in the filesystem.  fs_use_xattr tells SELinux to fetch
> the inode label via ->getxattr().  fs_use_task tells SELinux to assign
> the inode the label of its creator.  fs_use_trans tells SELinux to
> compute the inode label based on the result of security_transition_sid()
> on the creating process SID and the filesystem SID.  What
> security_transition_sid() returns depends on whether or not you have a
> transition rule in policy.  So fs_use_trans doesn't guarantee that you
> have a transition rule in place; it just allows you to use transition
> rules if you wish to label the inodes based on some combination of the
> creating process domain and the filesystem type.
> 

In light of the above, in what category do you think the following file systems would fall (if any):

aio, drm, anon_inodefs, bdev, efivarfs

I currently use genfscon for all of the above but i suspect that this is wrong for the above

They are initialized but do not show up in the mount table

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]