/dev/full

/dev/full

[Russell Coker]

Running a recent Debian kernel with latest git policy without the unconfined 
module I'm seeing the following.  Why would /dev/full be getting the wrong 
label early in the boot?  It gets fixed along the way somewhere before the 
system goes to multi-user mode.

# dmesg|grep event_device_t
[   11.282465] audit: type=1400 audit(1790509173.037:4): avc:  denied  { write 
} for  pid=534 comm="modprobe" name="full" dev="devtmpfs" ino=7 
scontext=system_u:system_r:kmod_t:s0 
tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0
# ls -lZi /dev/full
7 crw-rw-rw-. 1 root root system_u:object_r:null_device_t:s0 1, 7 Sep 27 21:39 
/dev/full
# uname -a
Linux babycakes 7.2.8+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.2.8-1 
(2026-09-26) x86_64 GNU/Linux

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: /dev/full

[Dominick Grift]

Russell Coker <russell@coker.com.au> writes:

> Running a recent Debian kernel with latest git policy without the unconfined 
> module I'm seeing the following.  Why would /dev/full be getting the wrong 
> label early in the boot?  It gets fixed along the way somewhere before the 
> system goes to multi-user mode.
>
> # dmesg|grep event_device_t
> [   11.282465] audit: type=1400 audit(1790509173.037:4): avc:  denied  { write 
> } for  pid=534 comm="modprobe" name="full" dev="devtmpfs" ino=7 
> scontext=system_u:system_r:kmod_t:s0 
> tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0
> # ls -lZi /dev/full
> 7 crw-rw-rw-. 1 root root system_u:object_r:null_device_t:s0 1, 7 Sep 27 21:39 
> /dev/full
> # uname -a
> Linux babycakes 7.2.8+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.2.8-1 
> (2026-09-26) x86_64 GNU/Linux

I noticed similar. I suspect this is due to how userspace_initial_sid
polcap is implemented in refpolicy (refpolicy does leverage it does it
not?). Misssing an appropriate auto type transition because the scenario
changed.


-- 
gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

Re: /dev/full

[Russell Coker]

On Monday, 28 September 2026 14:28:27 AEST Dominick Grift wrote:
> I noticed similar. I suspect this is due to how userspace_initial_sid
> polcap is implemented in refpolicy (refpolicy does leverage it does it
> not?). Misssing an appropriate auto type transition because the scenario
> changed.

The below is in current refpolicy, is this what you mean?

# Enable separate user space context for processes started before first
# policy load.
# Requires libsepol 3.7 and kernel 6.8.
#
# Added checks:
# (none)
policycap userspace_initial_context;

How do you think it could be affecting the issue I saw?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: /dev/full

[Dominick Grift]

Russell Coker <russell@coker.com.au> writes:

> On Monday, 28 September 2026 14:28:27 AEST Dominick Grift wrote:
>> I noticed similar. I suspect this is due to how userspace_initial_sid
>> polcap is implemented in refpolicy (refpolicy does leverage it does it
>> not?). Misssing an appropriate auto type transition because the scenario
>> changed.

The fact that it ends up event_device_t means that the wrong type
transition applies (theres a default for chr_file event_device_t which
is triggered instead of the proper name-based transition

the polcap mentioned can be used to implement a different context for
userspace processes in initrd. Depending on how its implemented it could
introduce issues like these (I encountered similar but my implementation
of that polcap is more intrusive.

For example: any transitions associated with kernel_t would no longer
apply to userspace in initrd if that is now given a private context.

>
> The below is in current refpolicy, is this what you mean?
>
> # Enable separate user space context for processes started before first
> # policy load.
> # Requires libsepol 3.7 and kernel 6.8.
> #
> # Added checks:
> # (none)
> policycap userspace_initial_context;
>
> How do you think it could be affecting the issue I saw?

-- 
gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

Re: /dev/full

[Dominick Grift]

Dominick Grift <dominick.grift@defensec.nl> writes:

> Russell Coker <russell@coker.com.au> writes:
>
>> On Monday, 28 September 2026 14:28:27 AEST Dominick Grift wrote:
>>> I noticed similar. I suspect this is due to how userspace_initial_sid
>>> polcap is implemented in refpolicy (refpolicy does leverage it does it
>>> not?). Misssing an appropriate auto type transition because the scenario
>>> changed.
>
> The fact that it ends up event_device_t means that the wrong type
> transition applies (theres a default for chr_file event_device_t which
> is triggered instead of the proper name-based transition
>
> the polcap mentioned can be used to implement a different context for
> userspace processes in initrd. Depending on how its implemented it could
> introduce issues like these (I encountered similar but my implementation
> of that polcap is more intrusive.
>
> For example: any transitions associated with kernel_t would no longer
> apply to userspace in initrd if that is now given a private context.


Could also be that the name-based transition for /dev/full was never
added because the event was not reproduced after name-based transitions
became available.

Bottom line: missing (name-based) type transition rule

>
>>
>> The below is in current refpolicy, is this what you mean?
>>
>> # Enable separate user space context for processes started before first
>> # policy load.
>> # Requires libsepol 3.7 and kernel 6.8.
>> #
>> # Added checks:
>> # (none)
>> policycap userspace_initial_context;
>>
>> How do you think it could be affecting the issue I saw?

-- 
gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

Re: /dev/full

[Russell Coker]

On Monday, 28 September 2026 20:34:23 AEST Dominick Grift wrote:
> Could also be that the name-based transition for /dev/full was never
> added because the event was not reproduced after name-based transitions
> became available.
> 
> Bottom line: missing (name-based) type transition rule

# sesearch -T -c chr_file|grep -v devpts_t|grep event
type_transition kernel_t device_t:chr_file event_device_t;

policy/modules/kernel/kernel.te: dev_filetrans_input_dev(kernel_t)

Thanks for that, it was a default trans rule.  I'll add a named transition for 
/dev/full

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: /dev/full

[Russell Coker]

On Monday, 28 September 2026 21:58:17 AEST Russell Coker wrote:
> On Monday, 28 September 2026 20:34:23 AEST Dominick Grift wrote:
> > Could also be that the name-based transition for /dev/full was never
> > added because the event was not reproduced after name-based transitions
> > became available.
> > 
> > Bottom line: missing (name-based) type transition rule
> 
> # sesearch -T -c chr_file|grep -v devpts_t|grep event
> type_transition kernel_t device_t:chr_file event_device_t;
> 
> policy/modules/kernel/kernel.te: dev_filetrans_input_dev(kernel_t)
> 
> Thanks for that, it was a default trans rule.  I'll add a named transition
> for /dev/full

That doesn't seem to work.

root@ami:~# sesearch -T -c chr_file|grep null
type_transition kernel_t device_t:chr_file null_device_t full;
root@ami:~# dmesg|grep event_device_t
[    3.269252] audit: type=1400 audit(1790597162.343:4): avc:  denied  { write 
} for  pid=330 comm="modprobe" name="full" dev="devtmpfs" ino=7 
scontext=system_u:system_r:kmod_t:s0 
tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0
[    3.272938] audit: type=1400 audit(1790597162.343:5): avc:  denied  { write 
} for  pid=332 comm="modprobe" name="full" dev="devtmpfs" ino=7 
scontext=system_u:system_r:kmod_t:s0 
tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: /dev/full

[Dominick Grift]

Russell Coker <russell@coker.com.au> writes:

> On Monday, 28 September 2026 21:58:17 AEST Russell Coker wrote:
>> On Monday, 28 September 2026 20:34:23 AEST Dominick Grift wrote:
>> > Could also be that the name-based transition for /dev/full was never
>> > added because the event was not reproduced after name-based transitions
>> > became available.
>> > 
>> > Bottom line: missing (name-based) type transition rule
>> 
>> # sesearch -T -c chr_file|grep -v devpts_t|grep event
>> type_transition kernel_t device_t:chr_file event_device_t;
>> 
>> policy/modules/kernel/kernel.te: dev_filetrans_input_dev(kernel_t)
>> 
>> Thanks for that, it was a default trans rule.  I'll add a named transition
>> for /dev/full
>
> That doesn't seem to work.
>
> root@ami:~# sesearch -T -c chr_file|grep null
> type_transition kernel_t device_t:chr_file null_device_t full;
> root@ami:~# dmesg|grep event_device_t
> [    3.269252] audit: type=1400 audit(1790597162.343:4): avc:  denied  { write 
> } for  pid=330 comm="modprobe" name="full" dev="devtmpfs" ino=7 
> scontext=system_u:system_r:kmod_t:s0 
> tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0
> [    3.272938] audit: type=1400 audit(1790597162.343:5): avc:  denied  { write 
> } for  pid=332 comm="modprobe" name="full" dev="devtmpfs" ino=7 
> scontext=system_u:system_r:kmod_t:s0 
> tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0

What is the context associated with the init sid? Maybe that is actually
creating it then?

-- 
gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl

Re: /dev/full

[Russell Coker]

On Monday, 28 September 2026 22:21:32 AEST Dominick Grift wrote:
> >> Thanks for that, it was a default trans rule.  I'll add a named
> >> transition
> >> for /dev/full
> > 
> > That doesn't seem to work.
> > 
> > root@ami:~# sesearch -T -c chr_file|grep null
> > type_transition kernel_t device_t:chr_file null_device_t full;
> > root@ami:~# dmesg|grep event_device_t
> > [    3.269252] audit: type=1400 audit(1790597162.343:4): avc:  denied  {
> > write } for  pid=330 comm="modprobe" name="full" dev="devtmpfs" ino=7
> > scontext=system_u:system_r:kmod_t:s0
> > tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0
> > [    3.272938] audit: type=1400 audit(1790597162.343:5): avc:  denied  {
> > write } for  pid=332 comm="modprobe" name="full" dev="devtmpfs" ino=7
> > scontext=system_u:system_r:kmod_t:s0
> > tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0
> 
> What is the context associated with the init sid? Maybe that is actually
> creating it then?

That's an interesting question, I get the following message in dmesy.

[   10.940969] systemd[1]: Failed to transition into init label 
'system_u:system_r:init_t:s0', ignoring: Permission denied

The following is the policy line you are probably interested in:

policy/modules/kernel/kernel.te:sid init 
gen_context(system_u:system_r:init_t,mls_systemhigh)

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: /dev/full

[Dominick Grift]

Russell Coker <russell@coker.com.au> writes:

> On Monday, 28 September 2026 22:21:32 AEST Dominick Grift wrote:
>> >> Thanks for that, it was a default trans rule.  I'll add a named
>> >> transition
>> >> for /dev/full
>> > 
>> > That doesn't seem to work.
>> > 
>> > root@ami:~# sesearch -T -c chr_file|grep null
>> > type_transition kernel_t device_t:chr_file null_device_t full;
>> > root@ami:~# dmesg|grep event_device_t
>> > [    3.269252] audit: type=1400 audit(1790597162.343:4): avc:  denied  {
>> > write } for  pid=330 comm="modprobe" name="full" dev="devtmpfs" ino=7
>> > scontext=system_u:system_r:kmod_t:s0
>> > tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0
>> > [    3.272938] audit: type=1400 audit(1790597162.343:5): avc:  denied  {
>> > write } for  pid=332 comm="modprobe" name="full" dev="devtmpfs" ino=7
>> > scontext=system_u:system_r:kmod_t:s0
>> > tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0
>> 
>> What is the context associated with the init sid? Maybe that is actually
>> creating it then?
>
> That's an interesting question, I get the following message in dmesy.
>
> [   10.940969] systemd[1]: Failed to transition into init label 
> 'system_u:system_r:init_t:s0', ignoring: Permission denied

Interesting but I dont think that is related. Maybe a
setcurrent/dyntransition is missing there.

>
> The following is the policy line you are probably interested in:
>
> policy/modules/kernel/kernel.te:sid init 
> gen_context(system_u:system_r:init_t,mls_systemhigh)

You could try: type_transition kernel_t device_t:chr_file null_device_t
full;

My reasoning:

1. whatever creates that /dev/full with event_device_t is very early
because otherwise udev and pid1 would have relabeled it by the time the
event happened.

2. That leaves either kernel_t or init_t. Some stuff that now runs in
init_t used to run in kernel_t previously. If its not kernel_t then that
leaves us with init_t.

-- 
gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl