Dominick Grift <[email protected]> writes: > Dominick Grift <[email protected]> writes: > >> Hi, Thank you for feedback. Comments inline below: >> >> Stefan Hellermann <[email protected]> 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 [email protected] (wkd) Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @[email protected] _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
