> what is the size increase in kmod-ext4 due to this? I think the overhead is small. Here are the kernel artifact sizes (KB) without security labels:
3176 ./build_dir/target-x86_64_musl/linux-x86_64/linux-4.14.79/arch/x86/boot/compressed/vmlinux 55624 ./build_dir/target-x86_64_musl/linux-x86_64/linux-4.14.79/vmlinux 11852 ./build_dir/target-x86_64_musl/linux-x86_64/vmlinux 3292 ./build_dir/target-x86_64_musl/linux-x86_64/root.grub/boot/vmlinuz Here they are with: 3176 ./build_dir/target-x86_64_musl/linux-x86_64/linux-4.14.79/arch/x86/boot/compressed/vmlinux 55632 ./build_dir/target-x86_64_musl/linux-x86_64/linux-4.14.79/vmlinux 11852 ./build_dir/target-x86_64_musl/linux-x86_64/vmlinux 3292 ./build_dir/target-x86_64_musl/linux-x86_64/root.grub/boot/vmlinuz What is less obvious is the runtime memory overhead. I suspect that the security labels themselves come at little cost, since they are so sparse. However, the extended-attribute infrastructure itself might cost something---it is not yet clear to me if this is present in every ext4 build or only those which include something like security labels or ACLs. I am also reading about "ambient capabilities" as proposed by Etienne. I wonder if we could wire these into the procd system. My near-term aim is to allow network services to run without root privileges. While many drop their privileges after using them to listen on a port < 1024 socket, I would rather they never run as root and instead rely on CAP_NET_BIND_SERVICE. Aside from less room for error in the service source code, it is nice to be able to specify users in the /etc/init.d files as opposed to per-service configuration mechanisms. This has become more pressing for me since I started using Go in more of my Linux work. Goroutines do not seem to play nicely with setuid [1], so on Go things like CAP_NET_BIND_SERVICE are preferred. I am building a few things in Go on OpenWrt. [1] https://github.com/golang/go/issues/1435 -- Mike :wq _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
