[PATCH 0/2] enable procd security features by default

Stijn Tintel stijn at linux-ipv6.be
Fri Nov 27 00:56:28 EST 2020


On 7/11/2020 16:17, Daniel Golle wrote:
> Hi all!
>
> A while ago we have added some useful kernel features to !SMALL_FLASH
> devices[1]. To make more use of that by default in a way which will
> make exploiting potential vulnerabilities in OpenWrt's services much
> harder, it'd be great to also have procd-ujail as well as procd-seccomp
> installed by default, adding about 38kB to squashfs rootfs.
>
> As it was reverted after it (actually something else) had broken the
> build, I've extensively tested ujail on x86/64, ath79/generic,
> ramips/mt7621, malta/mips64be and armvirt/64.
>
> Previous problems on MIPS64 systems (originating from a very strange
> compiler bug, but I was able to work around it) are fixed now, thanks
> to help from Roman Kuzmitskii (@damex).
>
> I must admit that I have no means to do any tests on PPC platforms and
> in order to avoid similar unexpected problems, it'd be great if someone
> with PPC hardware could test-run, simply by installing procd-ujail and
> procd-seccomp to their system and checking if everything still works as
> expected after a reboot (if there are problems you would notice dnsmasq
> and ntpd not coming up, as those would be jailed by default in case of
> /sbin/ujail being found).
>
> Please report back and voice any concens, it'd be great to have this
> included in OpenWrt 20.xx (xx == 11?)
>
> [1]: commit fcb41decf6 ("config: enable some useful features on !SMALL_FLASH devices")
>
>
> Daniel Golle (2):
>   target: select procd-ujail if !SMALL_FLASH
>   target: select procd-seccomp if kernel support is present
>
>  include/target.mk | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
Please have another look at de7ca7dafadfd650d031e0379ce0c002868d5936. It
does not work for devices running ext4 images. This caused me a night of
downtime and forced me to take an unpaid day off. I very much value the
work to move away from running everything as root, but breakage like
this is really not acceptable.




More information about the openwrt-devel mailing list