[PATCH] selinux-policy: update to version v2.0

Dominick Grift dominick.grift at defensec.nl
Mon Jan 13 09:52:54 PST 2025


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

> Dominick Grift <dominick.grift at defensec.nl> writes:
>
>> Hi, Thank you for feedback. Comments inline below:
>>
>> Stefan Hellermann <stefan at the2masters.de> writes:
>>
>
> <snip>
>
>>> audit(1736704702.290:4): avc:  denied  { associate } for  pid=1010
>>> comm="mv" name="sysupgrade.tgz" scontext=sys.id:sys.role:dos.fs
>>> tcontext=sys.id:sys.role:xattr.fs tclass=filesystem permissive=1
>>
>> This is caused by mv'ing the file from a fat filesystem (fat does not
>> support extended attributes) to an extended attribute file system. When
>> you mv a file you also mv its associated context with it.
>>
>> This should not be allowed. Instead you should use cp. mv does not make
>> much sense anyway cross filesystem.
>>
>
> This bothered me so I would like to explain why I object to this.
>
> mv and cp are more complicated than some think. I see this all the time
> where people for example use `cp -a` without realizing the consequences.
>
> But regardless of this, coreutils has extensive support for SELinux and
> `mv -Z` would have addressed the above challenge. The issue is that
> busybox' `mv` does not support -Z and so eventually I will have to draw
> the line somewhere anyway. This seems like a good place to start.
>
>>> Sun Jan 12 17:58:25 2025 user.warn kernel: urandom-seed: Seed file not
>>> found (/etc/urandom.seed)
>>> Sun Jan 12 17:58:25 2025 user.info kernel: procd: - early -
>>> Sun Jan 12 17:58:25 2025 kern.notice kernel: audit: type=1400
>>> audit(1736704702.590:5): avc:  denied  { write } for  pid=1166
>>> comm="mkdir" name="/" dev="tmpfs" ino=1
>>> scontext=sys.id:sys.role:hotplug.call.subj
>>> tcontext=sys.id:sys.role:tmp.fs tclass=dir permissive=1
>>> Sun Jan 12 17:58:25 2025 kern.notice kernel: audit: type=1400
>>> audit(1736704702.590:6): avc:  denied  { add_name } for  pid=1166
>>> comm="mkdir" name="virtio-ports"
>>> scontext=sys.id:sys.role:hotplug.call.subj
>>> tcontext=sys.id:sys.role:tmp.fs tclass=dir permissive=1
>>> Sun Jan 12 17:58:25 2025 kern.notice kernel: audit: type=1400
>>> audit(1736704702.590:7): avc:  denied  { create } for  pid=1166
>>> comm="mkdir" name="virtio-ports"
>>> scontext=sys.id:sys.role:hotplug.call.subj
>>> tcontext=sys.id:sys.role:tmp.fs tclass=dir permissive=1
>>> Sun Jan 12 17:58:25 2025 kern.notice kernel: audit: type=1400
>>> audit(1736704702.590:8): avc:  denied  { create } for  pid=1167
>>> comm="ln" name="org.qemu.guest_agent.0"
>>> scontext=sys.id:sys.role:hotplug.call.subj
>>> tcontext=sys.id:sys.role:tmp.fs tclass=lnk_file permissive=1
>>> Sun Jan 12 17:58:25 2025 user.info kernel: procd: - ubus -
>>> Sun Jan 12 17:58:25 2025 user.info kernel: procd: - init -

I added support for this. We'll see where this leads. I might end up
reverting it later.

https://git.defensec.nl/?p=selinux-policy.git;a=commitdiff;h=32c0cc897f679b6d2b204bc2935d9de3b7006944

>>
>> This seems like an 'exotic hotplug script'. I have an accomodation for
>> this. see if this comment helps:
>> https://git.defensec.nl/?p=selinux-policy.git;a=blob;f=src/agent/sysagent/hotplugsysagent.cil;h=3987b8540ae537d174a74cceb2c89ce26ef3c813;hb=HEAD#l115
>
> We'll have to see how this will work out practically. I am open to
> suggestions for alternative approaches but this seems like a fair
> approach.
>
> There are also challenges here. For example in the above event, the
> script is trying to create a dir and symlink in /dev. In OpenWrt there
> is no (easy) way to make a distinction between devtmpfs and and a common
> tmpfs. If I we're to allow this then that would later potentially
> present challenges when another script wants to create a dir or symlink in /tmp.
>
> Again, eventually I would have to draw the line somewhere as to what
> should be allowed by default and what is to be considered exotic. This
> looks like a good place.
>
> Just trying to explain some of the rationale because I am open to better
> alternatives. I just don't see any.

-- 
gpg --locate-keys dominick.grift at defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod at defensec.nl



More information about the openwrt-devel mailing list