Re: kernel access to device comm is kdevtmpfs

Re: kernel access to device comm is kdevtmpfs

[Stephen Smalley]

On 08/26/2015 12:33 AM, Roberts, William C wrote:
> I get these records with comm set to kdevtempfs. The targert context is
> device, however when interrogating the node from userspace, I notice 2
> things:
> 
>  
> 
> 1.       The inode doesn’t match
> 
> 2.       The label is correct per file_contexts
> 
>  
> 
> root@device:/dev # ls -laiZ media0                                      
> 
>    10000 crw-rw---- system   camera           
> u:object_r:camera_device:s0 media0
> 
> root@device:/dev # ls -laiZ ttyS1                                      
> 
>     1217 crw-rw---- bluetooth bluetooth         
> u:object_r:hci_attach_dev:s0 ttyS1
> 
>  
> 
> [    4.421817] audit: type=1400 audit(1263534127.178:4): avc:  denied  {
> write } for  pid=24 comm="kdevtmpfs" name="/" dev="devtmpfs" ino=1025
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [    4.421859] audit: type=1400 audit(1263534127.178:5): avc:  denied  {
> add_name } for  pid=24 comm="kdevtmpfs" name="dm-0"
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [    5.745165] type=1400 audit(1263534128.499:23): avc: denied { getattr
> } for pid=24 comm="kdevtmpfs" path="/ttyS1" dev="devtmpfs" ino=1051
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=chr_file
> permissive=1
> 
> [    5.746180] type=1400 audit(1263534128.499:24): avc: denied { setattr
> } for pid=24 comm="kdevtmpfs" name="ttyS1" dev="devtmpfs" ino=1051
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=chr_file
> permissive=1
> 
> [    5.746384] type=1400 audit(1263534128.499:25): avc: denied {
> remove_name } for pid=24 comm="kdevtmpfs" name="ttyS1" dev="devtmpfs"
> ino=1051 scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir
> permissive=1
> 
> [    5.746742] type=1400 audit(1263534128.499:26): avc: denied { unlink
> } for pid=24 comm="kdevtmpfs" name="ttyS1" dev="devtmpfs" ino=1051
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=chr_file
> permissive=1
> 
> [    5.746966] type=1400 audit(1263534128.500:27): avc: denied { create
> } for pid=24 comm="kdevtmpfs" name="ttyS1" scontext=u:r:kernel:s0
> tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
> 
> [    7.605775] type=1400 audit(1263534130.358:35): avc: denied { write }
> for pid=24 comm="kdevtmpfs" name="/" dev="devtmpfs" ino=1025
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [    7.606116] type=1400 audit(1263534130.358:36): avc: denied {
> add_name } for pid=24 comm="kdevtmpfs" name="media0"
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [    7.606350] type=1400 audit(1263534130.358:37): avc: denied { create
> } for pid=24 comm="kdevtmpfs" name="media0" scontext=u:r:kernel:s0
> tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
> 
> [    7.606582] type=1400 audit(1263534130.358:38): avc: denied { setattr
> } for pid=24 comm="kdevtmpfs" name="media0" dev="devtmpfs" ino=9999
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=chr_file
> permissive=1
> 
> [   10.152747] type=1400 audit(1263534132.902:52): avc: denied { write }
> for pid=24 comm="kdevtmpfs" name="/" dev="devtmpfs" ino=1025
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [   10.153026] type=1400 audit(1263534132.902:53): avc: denied {
> add_name } for pid=24 comm="kdevtmpfs" name="dm-1"
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [    4.421817] audit: type=1400 audit(1263534127.178:4): avc:  denied  {
> write } for  pid=24 comm="kdevtmpfs" name="/" dev="devtmpfs" ino=1025
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [    4.421859] audit: type=1400 audit(1263534127.178:5): avc:  denied  {
> add_name } for  pid=24 comm="kdevtmpfs" name="dm-0"
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [    5.745165] type=1400 audit(1263534128.499:23): avc: denied { getattr
> } for pid=24 comm="kdevtmpfs" path="/ttyS1" dev="devtmpfs" ino=1051
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=chr_file
> permissive=1
> 
> [    5.746180] type=1400 audit(1263534128.499:24): avc: denied { setattr
> } for pid=24 comm="kdevtmpfs" name="ttyS1" dev="devtmpfs" ino=1051
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=chr_file
> permissive=1
> 
> [    5.746384] type=1400 audit(1263534128.499:25): avc: denied {
> remove_name } for pid=24 comm="kdevtmpfs" name="ttyS1" dev="devtmpfs"
> ino=1051 scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir
> permissive=1
> 
> [    5.746742] type=1400 audit(1263534128.499:26): avc: denied { unlink
> } for pid=24 comm="kdevtmpfs" name="ttyS1" dev="devtmpfs" ino=1051
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=chr_file
> permissive=1
> 
> [    5.746966] type=1400 audit(1263534128.500:27): avc: denied { create
> } for pid=24 comm="kdevtmpfs" name="ttyS1" scontext=u:r:kernel:s0
> tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
> 
> [    7.605775] type=1400 audit(1263534130.358:35): avc: denied { write }
> for pid=24 comm="kdevtmpfs" name="/" dev="devtmpfs" ino=1025
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [    7.606116] type=1400 audit(1263534130.358:36): avc: denied {
> add_name } for pid=24 comm="kdevtmpfs" name="media0"
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [    7.606350] type=1400 audit(1263534130.358:37): avc: denied { create
> } for pid=24 comm="kdevtmpfs" name="media0" scontext=u:r:kernel:s0
> tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
> 
> [    7.606582] type=1400 audit(1263534130.358:38): avc: denied { setattr
> } for pid=24 comm="kdevtmpfs" name="media0" dev="devtmpfs" ino=9999
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=chr_file
> permissive=1
> 
> [   10.152747] type=1400 audit(1263534132.902:52): avc: denied { write }
> for pid=24 comm="kdevtmpfs" name="/" dev="devtmpfs" ino=1025
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
> [   10.153026] type=1400 audit(1263534132.902:53): avc: denied {
> add_name } for pid=24 comm="kdevtmpfs" name="dm-1"
> scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
> 
>  
> 
> Ive never really ran into these before, can someone perhaps enlighten me
> as to what’s going on here?

This implies you have CONFIG_DEVTMPFS=y in your kernel config (and maybe
CONFIG_DEVTMPFS_MOUNT=y?). That hasn't been present in Android kernels
to date AFAIK, so current Android SELinux policy doesn't support it.
What do you actually have mounted on /dev - devtmpfs or regular tmpfs
(look at /proc/self/mounts)?

With devtmpfs, the kernel itself automatically populates and maintains a
device node tree.  The claim is that this provides you with a working
/dev tree before udev comes up, and that you can even dispense with
running udev entirely on simple systems (e.g. embedded).  However, it
seems like everyone continues to run udev on top of devtmpfs in Linux
distributions.

The problem of course is that the kernel has no clue how to label the
device nodes, so it is still necessary to have udev or ueventd handle
that.  And with the kernel creation of the device nodes, we then have a
race condition where the device node briefly exists in the wrong, most
likely inaccessible label.

Fedora has tried to work around this by defining name-based type
transitions for the kernel domain on /dev to label the device nodes
correctly on creation.  However, name-based type transitions aren't well
suited to that purpose; they only support exact match (no prefix, glob,
or regex matching), they only match the last component, and they were
only intended to cover exceptional cases where regular type transitions
weren't sufficiently granular and one couldn't modify the creating
program to explicitly label the file based on file_contexts (so they
aren't designed to scale well).  Maybe we could use genfs_contexts
instead (i.e. add devtmpfs to the list of filesystems that have
SE_SBGENFS set in sbsec->flags, then you can specify path prefixes
relative to the root of devtmpfs and label them that way).

But first you ought to decide whether you truly want devtmpfs at all,
and whether you are actually using it, or just overlaying it with a
regular tmpfs mount in userspace.

Re: kernel access to device comm is kdevtmpfs

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Aug 26, 2015 at 09:47:31AM -0400, Stephen Smalley wrote:

<snip>

> 
> Fedora has tried to work around this by defining name-based type
> transitions for the kernel domain on /dev to label the device nodes
> correctly on creation.  However, name-based type transitions aren't well
> suited to that purpose; they only support exact match (no prefix, glob,
> or regex matching), they only match the last component, and they were
> only intended to cover exceptional cases where regular type transitions
> weren't sufficiently granular and one couldn't modify the creating
> program to explicitly label the file based on file_contexts (so they
> aren't designed to scale well).  Maybe we could use genfs_contexts
> instead (i.e. add devtmpfs to the list of filesystems that have
> SE_SBGENFS set in sbsec->flags, then you can specify path prefixes
> relative to the root of devtmpfs and label them that way).

This sounds like a good idea to me.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJV3cf/AAoJENAR6kfG5xmc88gL+gLY44J62XK0v//hjLWtg9yk
fZLOvjQNJ0B1zsWhYWarJ/mxleToKLwZSDhNSinkjzvDzw2zTwCl6D5pf9JSp1cr
5IreQ/XTM4VDmUJqd45NReInWzwwn23lva2qHWrxk15RzWqAEvn+2lByUE/uk5ca
hKL173klBg2MVjS4hfafSm4h9KTvTB0mkMmcMbi9PzhzCqzqjB8Q6uJnzKQ9pGtT
i7ibHrQUNE18z9qRs3LQEaoTujdcTyvTL88f3nrdCGlJkihJe59Qm6lGv/UiFbbY
MRVpVdc4pC4sOr5+zNpD892L/L619gOtW0/5FpxWnBghHw46+G5p4ZAB79S+anfO
C5w0Rr5lQ0dYgAiV6wDCQZoBaw6PlOREtATe7WqOf7hAd7KGzYoRkuKdcYBMiEjj
XHqX8kXyKsoBl4k71LWHGGQyMAWunjrfxQCrpn37B4089jMJrJYbyXHeVHUo7X56
syh9uNPV2FMUey7wsuDXJ8C5PFZU8B1HP1PDXDLepQ==
=Wpna
-----END PGP SIGNATURE-----

Re: kernel access to device comm is kdevtmpfs

[Nick Kralevich]

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

On Wed, Aug 26, 2015 at 6:47 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> With devtmpfs, the kernel itself automatically populates and maintains a
> device node tree.  The claim is that this provides you with a working
> /dev tree before udev comes up, and that you can even dispense with
> running udev entirely on simple systems (e.g. embedded).  However, it
> seems like everyone continues to run udev on top of devtmpfs in Linux
> distributions.
>
> The problem of course is that the kernel has no clue how to label the
> device nodes, so it is still necessary to have udev or ueventd handle
> that.  And with the kernel creation of the device nodes, we then have a
> race condition where the device node briefly exists in the wrong, most
> likely inaccessible label.
>
>
Do you know how other standard DAC permissions are configured by the
kernel? The kernel must have some knowledge of how to set the
UID/GID/perms/etc...

-- Nick

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

Re: kernel access to device comm is kdevtmpfs

[Stephen Smalley]

On 08/26/2015 12:10 PM, Nick Kralevich wrote:
> 
> 
> On Wed, Aug 26, 2015 at 6:47 AM, Stephen Smalley <sds@tycho.nsa.gov
> <mailto:sds@tycho.nsa.gov>> wrote:
> 
>     With devtmpfs, the kernel itself automatically populates and maintains a
>     device node tree.  The claim is that this provides you with a working
>     /dev tree before udev comes up, and that you can even dispense with
>     running udev entirely on simple systems (e.g. embedded).  However, it
>     seems like everyone continues to run udev on top of devtmpfs in Linux
>     distributions.
> 
>     The problem of course is that the kernel has no clue how to label the
>     device nodes, so it is still necessary to have udev or ueventd handle
>     that.  And with the kernel creation of the device nodes, we then have a
>     race condition where the device node briefly exists in the wrong, most
>     likely inaccessible label.
> 
> 
> Do you know how other standard DAC permissions are configured by the
> kernel? The kernel must have some knowledge of how to set the
> UID/GID/perms/etc...

As per drivers/base/devtmpfs.c, they default to root ownership and mode
0600 unless overridden by the driver.  Otherwise it is up to
udev/ueventd to fix up the permissions afterward.

The situation for SELinux contexts is similar (they will default to
device type until fixed by udev/ueventd), but we are more likely to run
afoul of race conditions because we don't allow all root processes to
access all device nodes. So we can end up denying access that would be
allowed once the label is correctly set by udev/ueventd.

Fedora currently avoids this via lots of name-based type transitions on
(kernel, device, chr_file|blk_file) but that is decidedly suboptimal.

We could certainly add devtmpfs to the list of filesystems for which we
support per-file genfs_contexts-based labeling, and then add /dev
entries there (prefix match, not regex match).

But I guess the question is why use devtmpfs at all if you are going to
run udev/ueventd anyway.  What's the practical benefit?

Re: kernel access to device comm is kdevtmpfs

[William Roberts]

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

Looks like its a normal tmpfs
<snip>
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
<snip>

I don't see anything else overlaying /dev mount point.

I currently dont have anything attempting to access it outside of kernel
domain...

One of the best features of SELinux is finding issues in various things,
like DAC perms. Perhaps,
I can get kdevtmpfs dropped, I see no use for it here.

Thanks,
Bill



On Wed, Aug 26, 2015 at 9:25 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 08/26/2015 12:10 PM, Nick Kralevich wrote:
> >
> >
> > On Wed, Aug 26, 2015 at 6:47 AM, Stephen Smalley <sds@tycho.nsa.gov
> > <mailto:sds@tycho.nsa.gov>> wrote:
> >
> >     With devtmpfs, the kernel itself automatically populates and
> maintains a
> >     device node tree.  The claim is that this provides you with a working
> >     /dev tree before udev comes up, and that you can even dispense with
> >     running udev entirely on simple systems (e.g. embedded).  However, it
> >     seems like everyone continues to run udev on top of devtmpfs in Linux
> >     distributions.
> >
> >     The problem of course is that the kernel has no clue how to label the
> >     device nodes, so it is still necessary to have udev or ueventd handle
> >     that.  And with the kernel creation of the device nodes, we then
> have a
> >     race condition where the device node briefly exists in the wrong,
> most
> >     likely inaccessible label.
> >
> >
> > Do you know how other standard DAC permissions are configured by the
> > kernel? The kernel must have some knowledge of how to set the
> > UID/GID/perms/etc...
>
> As per drivers/base/devtmpfs.c, they default to root ownership and mode
> 0600 unless overridden by the driver.  Otherwise it is up to
> udev/ueventd to fix up the permissions afterward.
>
> The situation for SELinux contexts is similar (they will default to
> device type until fixed by udev/ueventd), but we are more likely to run
> afoul of race conditions because we don't allow all root processes to
> access all device nodes. So we can end up denying access that would be
> allowed once the label is correctly set by udev/ueventd.
>
> Fedora currently avoids this via lots of name-based type transitions on
> (kernel, device, chr_file|blk_file) but that is decidedly suboptimal.
>
> We could certainly add devtmpfs to the list of filesystems for which we
> support per-file genfs_contexts-based labeling, and then add /dev
> entries there (prefix match, not regex match).
>
> But I guess the question is why use devtmpfs at all if you are going to
> run udev/ueventd anyway.  What's the practical benefit?
>
> _______________________________________________
> Seandroid-list mailing list
> Seandroid-list@tycho.nsa.gov
> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Seandroid-list-request@tycho.nsa.gov.
>



-- 
Respectfully,

William C Roberts

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

Re: kernel access to device comm is kdevtmpfs

[Stephen Smalley]

On 08/26/2015 10:07 AM, Dominick Grift wrote:
> On Wed, Aug 26, 2015 at 09:47:31AM -0400, Stephen Smalley wrote:
> 
> <snip>
> 
> 
>> Fedora has tried to work around this by defining name-based type
>> transitions for the kernel domain on /dev to label the device nodes
>> correctly on creation.  However, name-based type transitions aren't well
>> suited to that purpose; they only support exact match (no prefix, glob,
>> or regex matching), they only match the last component, and they were
>> only intended to cover exceptional cases where regular type transitions
>> weren't sufficiently granular and one couldn't modify the creating
>> program to explicitly label the file based on file_contexts (so they
>> aren't designed to scale well).  Maybe we could use genfs_contexts
>> instead (i.e. add devtmpfs to the list of filesystems that have
>> SE_SBGENFS set in sbsec->flags, then you can specify path prefixes
>> relative to the root of devtmpfs and label them that way).
> 
> This sounds like a good idea to me.

Unfortunately, I was wrong.  Merely setting SE_SBGENFS in sbsec->flags
for devtmpfs filesystems does NOT enable genfs_context-based labeling of
devtmpfs files, because devtmpfs is tmpfs-backed, and tmpfs, like ext4,
calls security_inode_init_security() upon new inode creation to
explicitly initialize the in-core inode security state and to obtain the
xattr name/value pair.  That's why type transitions work for devtmpfs
(and tmpfs).  Filesystems that use genfscon-based labeling (e.g. proc,
sysfs, debugfs, pstore) do not support userspace file creation and
therefore do not call that hook and their inode security state is
initialized upon security_d_instantiate(), at which point we have a
dentry and can therefore generate a path relative to the root.
So we can't do this as a one-liner patch; it would be more involved.
devtmpfs/tmpfs does ultimately call d_instantiate() ->
security_d_instantiate(), but at that point the inode security state is
already initialized in the usual way and we therefore don't do anything
further with it.  We would need to rework the way inode security
initialization works, and do it in a way that avoids weird side effects
(e.g. if the policy defines a type transition, as in current Fedora
policy, we don't want to override that with a genfscon-based lookup).

Re: kernel access to device comm is kdevtmpfs

[William Roberts]

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

The best solution is to remove it if not needed. Android supports a full
udev userspace (full enough). So removing this is the direction I'm headed.
On Aug 28, 2015 6:24 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:

> On 08/26/2015 10:07 AM, Dominick Grift wrote:
> > On Wed, Aug 26, 2015 at 09:47:31AM -0400, Stephen Smalley wrote:
> >
> > <snip>
> >
> >
> >> Fedora has tried to work around this by defining name-based type
> >> transitions for the kernel domain on /dev to label the device nodes
> >> correctly on creation.  However, name-based type transitions aren't well
> >> suited to that purpose; they only support exact match (no prefix, glob,
> >> or regex matching), they only match the last component, and they were
> >> only intended to cover exceptional cases where regular type transitions
> >> weren't sufficiently granular and one couldn't modify the creating
> >> program to explicitly label the file based on file_contexts (so they
> >> aren't designed to scale well).  Maybe we could use genfs_contexts
> >> instead (i.e. add devtmpfs to the list of filesystems that have
> >> SE_SBGENFS set in sbsec->flags, then you can specify path prefixes
> >> relative to the root of devtmpfs and label them that way).
> >
> > This sounds like a good idea to me.
>
> Unfortunately, I was wrong.  Merely setting SE_SBGENFS in sbsec->flags
> for devtmpfs filesystems does NOT enable genfs_context-based labeling of
> devtmpfs files, because devtmpfs is tmpfs-backed, and tmpfs, like ext4,
> calls security_inode_init_security() upon new inode creation to
> explicitly initialize the in-core inode security state and to obtain the
> xattr name/value pair.  That's why type transitions work for devtmpfs
> (and tmpfs).  Filesystems that use genfscon-based labeling (e.g. proc,
> sysfs, debugfs, pstore) do not support userspace file creation and
> therefore do not call that hook and their inode security state is
> initialized upon security_d_instantiate(), at which point we have a
> dentry and can therefore generate a path relative to the root.
> So we can't do this as a one-liner patch; it would be more involved.
> devtmpfs/tmpfs does ultimately call d_instantiate() ->
> security_d_instantiate(), but at that point the inode security state is
> already initialized in the usual way and we therefore don't do anything
> further with it.  We would need to rework the way inode security
> initialization works, and do it in a way that avoids weird side effects
> (e.g. if the policy defines a type transition, as in current Fedora
> policy, we don't want to override that with a genfscon-based lookup).
> _______________________________________________
> Seandroid-list mailing list
> Seandroid-list@tycho.nsa.gov
> To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Seandroid-list-request@tycho.nsa.gov.
>

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

Re: kernel access to device comm is kdevtmpfs

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, Aug 28, 2015 at 07:11:21AM -0700, William Roberts wrote:
> The best solution is to remove it if not needed. Android supports a full
> udev userspace (full enough). So removing this is the direction I'm headed.
> On Aug 28, 2015 6:24 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:

Sure, but this thread mixes up two topics.

1. to use devtmpfs or not to use devtmpfs
2. support genfscon style labeling for devtmpfs

I was focussing on the second question, and i saw no reason not to
support genfscon style labeling for devtmpfs, as it would have just
provided more flexibility and it wouldnt force anyone into anything.

Not that it matters now though. Since it turns out to not be so
straightforward to add this functionality

> 
> > On 08/26/2015 10:07 AM, Dominick Grift wrote:
> > > On Wed, Aug 26, 2015 at 09:47:31AM -0400, Stephen Smalley wrote:
> > >
> > > <snip>
> > >
> > >
> > >> Fedora has tried to work around this by defining name-based type
> > >> transitions for the kernel domain on /dev to label the device nodes
> > >> correctly on creation.  However, name-based type transitions aren't well
> > >> suited to that purpose; they only support exact match (no prefix, glob,
> > >> or regex matching), they only match the last component, and they were
> > >> only intended to cover exceptional cases where regular type transitions
> > >> weren't sufficiently granular and one couldn't modify the creating
> > >> program to explicitly label the file based on file_contexts (so they
> > >> aren't designed to scale well).  Maybe we could use genfs_contexts
> > >> instead (i.e. add devtmpfs to the list of filesystems that have
> > >> SE_SBGENFS set in sbsec->flags, then you can specify path prefixes
> > >> relative to the root of devtmpfs and label them that way).
> > >
> > > This sounds like a good idea to me.
> >
> > Unfortunately, I was wrong.  Merely setting SE_SBGENFS in sbsec->flags
> > for devtmpfs filesystems does NOT enable genfs_context-based labeling of
> > devtmpfs files, because devtmpfs is tmpfs-backed, and tmpfs, like ext4,
> > calls security_inode_init_security() upon new inode creation to
> > explicitly initialize the in-core inode security state and to obtain the
> > xattr name/value pair.  That's why type transitions work for devtmpfs
> > (and tmpfs).  Filesystems that use genfscon-based labeling (e.g. proc,
> > sysfs, debugfs, pstore) do not support userspace file creation and
> > therefore do not call that hook and their inode security state is
> > initialized upon security_d_instantiate(), at which point we have a
> > dentry and can therefore generate a path relative to the root.
> > So we can't do this as a one-liner patch; it would be more involved.
> > devtmpfs/tmpfs does ultimately call d_instantiate() ->
> > security_d_instantiate(), but at that point the inode security state is
> > already initialized in the usual way and we therefore don't do anything
> > further with it.  We would need to rework the way inode security
> > initialization works, and do it in a way that avoids weird side effects
> > (e.g. if the policy defines a type transition, as in current Fedora
> > policy, we don't want to override that with a genfscon-based lookup).
> > _______________________________________________
> > Seandroid-list mailing list
> > Seandroid-list@tycho.nsa.gov
> > To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to
> > Seandroid-list-request@tycho.nsa.gov.
> >

> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.


- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJV4G+7AAoJENAR6kfG5xmc2ZsMAKJ4QmUjoFpDlvvTHe56OzLq
wFNdebybP7q7D6/5brKuZjLhbrZYXPi+UgJzjy4w8K0T9qaMe0LWX6yHp8hNFwwb
w0NcJJttJxMtLeH/K5KzDRFHE8qiJwQkhCrcoTecFm/9/Ho08Z1G5v0MjSbrdqKg
pVkx2ZmzdN2WI6GH+lb7xTXfBUipylqMq7jLDyXPXxBAcjLhVsY+zS+vEcMzCUwr
eyb6pc2KIEa1jH98gplEToHU24P1SdeJf+AkJZM0pTexb3t/010SQHc2w67um8tA
+t5vEMp8jQxGIp56YmKqvGFAJChwRskYm/+5ghDcXZmMaSfrYIe1bHUFWbYLxJCV
sagT45FZBiVYPp/CE0OR8LAciIRnhTe8pb0Nek0US88OPY61n7rxnvpKzn+y2k2i
r9P6z9O8MygoOxARCDaIaEIPwCe1qbuWShH6vErN45EgL2shE55Jge11TD9U/APM
aBuEC6J6LJDNIMWfVcVKxM54/UhZCcbQcUOuyEKzbA==
=sL/v
-----END PGP SIGNATURE-----

Re: kernel access to device comm is kdevtmpfs

[William Roberts]

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

On Fri, Aug 28, 2015 at 7:27 AM, Dominick Grift <dac.override@gmail.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Fri, Aug 28, 2015 at 07:11:21AM -0700, William Roberts wrote:
> > The best solution is to remove it if not needed. Android supports a full
> > udev userspace (full enough). So removing this is the direction I'm
> headed.
> > On Aug 28, 2015 6:24 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
>
> Sure, but this thread mixes up two topics.
>
> 1. to use devtmpfs or not to use devtmpfs
> 2. support genfscon style labeling for devtmpfs
>
> I was focussing on the second question, and i saw no reason not to
> support genfscon style labeling for devtmpfs, as it would have just
> provided more flexibility and it wouldnt force anyone into anything.
>
> Not that it matters now though. Since it turns out to not be so
> straightforward to add this functionality
>

Yes for the general case. However, this is the specific case of Android,
which I see no great reason to need it.


>
> >
> > > On 08/26/2015 10:07 AM, Dominick Grift wrote:
> > > > On Wed, Aug 26, 2015 at 09:47:31AM -0400, Stephen Smalley wrote:
> > > >
> > > > <snip>
> > > >
> > > >
> > > >> Fedora has tried to work around this by defining name-based type
> > > >> transitions for the kernel domain on /dev to label the device nodes
> > > >> correctly on creation.  However, name-based type transitions aren't
> well
> > > >> suited to that purpose; they only support exact match (no prefix,
> glob,
> > > >> or regex matching), they only match the last component, and they
> were
> > > >> only intended to cover exceptional cases where regular type
> transitions
> > > >> weren't sufficiently granular and one couldn't modify the creating
> > > >> program to explicitly label the file based on file_contexts (so they
> > > >> aren't designed to scale well).  Maybe we could use genfs_contexts
> > > >> instead (i.e. add devtmpfs to the list of filesystems that have
> > > >> SE_SBGENFS set in sbsec->flags, then you can specify path prefixes
> > > >> relative to the root of devtmpfs and label them that way).
> > > >
> > > > This sounds like a good idea to me.
> > >
> > > Unfortunately, I was wrong.  Merely setting SE_SBGENFS in sbsec->flags
> > > for devtmpfs filesystems does NOT enable genfs_context-based labeling
> of
> > > devtmpfs files, because devtmpfs is tmpfs-backed, and tmpfs, like ext4,
> > > calls security_inode_init_security() upon new inode creation to
> > > explicitly initialize the in-core inode security state and to obtain
> the
> > > xattr name/value pair.  That's why type transitions work for devtmpfs
> > > (and tmpfs).  Filesystems that use genfscon-based labeling (e.g. proc,
> > > sysfs, debugfs, pstore) do not support userspace file creation and
> > > therefore do not call that hook and their inode security state is
> > > initialized upon security_d_instantiate(), at which point we have a
> > > dentry and can therefore generate a path relative to the root.
> > > So we can't do this as a one-liner patch; it would be more involved.
> > > devtmpfs/tmpfs does ultimately call d_instantiate() ->
> > > security_d_instantiate(), but at that point the inode security state is
> > > already initialized in the usual way and we therefore don't do anything
> > > further with it.  We would need to rework the way inode security
> > > initialization works, and do it in a way that avoids weird side effects
> > > (e.g. if the policy defines a type transition, as in current Fedora
> > > policy, we don't want to override that with a genfscon-based lookup).
> > > _______________________________________________
> > > Seandroid-list mailing list
> > > Seandroid-list@tycho.nsa.gov
> > > To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
> > > To get help, send an email containing "help" to
> > > Seandroid-list-request@tycho.nsa.gov.
> > >
>
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.
>
>
> - --
> 02DFF788
> 4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
> http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
> Dominick Grift
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQGcBAEBCgAGBQJV4G+7AAoJENAR6kfG5xmc2ZsMAKJ4QmUjoFpDlvvTHe56OzLq
> wFNdebybP7q7D6/5brKuZjLhbrZYXPi+UgJzjy4w8K0T9qaMe0LWX6yHp8hNFwwb
> w0NcJJttJxMtLeH/K5KzDRFHE8qiJwQkhCrcoTecFm/9/Ho08Z1G5v0MjSbrdqKg
> pVkx2ZmzdN2WI6GH+lb7xTXfBUipylqMq7jLDyXPXxBAcjLhVsY+zS+vEcMzCUwr
> eyb6pc2KIEa1jH98gplEToHU24P1SdeJf+AkJZM0pTexb3t/010SQHc2w67um8tA
> +t5vEMp8jQxGIp56YmKqvGFAJChwRskYm/+5ghDcXZmMaSfrYIe1bHUFWbYLxJCV
> sagT45FZBiVYPp/CE0OR8LAciIRnhTe8pb0Nek0US88OPY61n7rxnvpKzn+y2k2i
> r9P6z9O8MygoOxARCDaIaEIPwCe1qbuWShH6vErN45EgL2shE55Jge11TD9U/APM
> aBuEC6J6LJDNIMWfVcVKxM54/UhZCcbQcUOuyEKzbA==
> =sL/v
> -----END PGP SIGNATURE-----
>



-- 
Respectfully,

William C Roberts

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