Maybe it should be something like: ```bash groupadd ubus for user in "root ..."; do usermod -a -G ubus "${user}" done
chgrp ubus /sbin/uci /var/run/ubus.sock chmod g+rw /var/run/ubus.sock chmod g+rwx /sbin/uci chmod o-rwx /sbin/uci /var/run/ubus.sock ``` What would this break? https://openwrt.org/docs/techref/ubus ... Better sandboxing in procd than chroot could be an objective. IDK where the previous discussions are? https://openwrt.org/docs/techref/procd cgroups without systemd: https://wiki.archlinux.org/index.php/cgroups#With_libcgroup Notes re: SELinux (and containers) https://github.com/rancher/k3s/issues/1372#issuecomment-581797716 https://blog.openshift.com/securing-kubernetes/ > > The main thing to understand about SELinux integration with OpenShift >> is that, by default, OpenShift runs each container as a random uid and is >> isolated with SELinux MCS labels. The easiest way of thinking about MCS >> labels is they are a dynamic way of getting SELinux separation without >> having to create policy files and run restorecon. >> >> If you are wondering why we need SELinux and namespaces at the same >> time, the way I view it is namespaces provide the nice abstraction but are >> not designed from a security first perspective. SELinux is the brick wall >> that’s going to stop you if you manage to break out of (accidentally or on >> purpose) from the namespace abstraction. >> >> CGroups is the remaining piece of the puzzle. Its primary purpose >> isn’t security, but I list it because it regulates that different >> containers stay within their allotted space for compute resources (cpu, >> memory, I/O). So without cgroups, you can’t be confident your application >> won’t be stomped on by another application on the same node. >> > Everybody's doing it: https://en.wikipedia.org/wiki/Seccomp#Software_using_seccomp_or_seccomp-bpf On Sat, Apr 18, 2020 at 10:22 PM Joel Wirāmu Pauling <j...@aenertia.net> wrote: > I'm sorry for wading into this. As with any security related discussion > strawpeople can be made to support any particular thread pulling into > infinity. > > Would I love to see namespaces used as part of the base Openwrt > architecture; absolutely. It's been discussed in the past; routing in > particular would benefit immensely from this ; use of different routing > table ID's is a step towards that, but complications like passing device > id's in and out of namespaces however for the switch side of things is > problematic and adds additional overhead as will it introduce issues at the > expense of separation and flexibility. > > That potentially could mitigate some of your concerns, but I feel the > preposition for me is openwrt is not multi-user by default OOTB for most > (if not all) targets; and if you want it to be you can. > > So fiddling inode bitmasks is not addressing anything IMNSHO because of > that fact. > > > > > > > On Sat, 18 Apr 2020 at 00:50, Wes Turner <wes.tur...@gmail.com> wrote: > >> From a least privileges perspective: >> >> - chmod o-rwx /var/run/hostapd-phyX.conf >> - chmod o-x uci # setfacl? >> >> Compromise of a service running as a different user should not result in >> disclosure of sensitive keys only necessary for different services. >> >> https://openwrt.org/docs/guide-user/security/security-features mentions >> procd jail / chroot? >> >> AFAIU, LXC is not available in the default kernel builds in any router? >> LXC would be an additional layer of defenses over and above chroot, which >> isn't seccomp >> >> On Fri, Apr 17, 2020, 5:13 AM Joel Wirāmu Pauling <j...@aenertia.net> >> wrote: >> >>> No. If you have physical access to the node and/or a valid login as >>> Admin then any form of PSK is vulnerable. >>> >>> If you are concerned about PSK's being exposed then you have the option >>> to run 802.1x auth and issue issues tokens out of radius/IDM that is >>> secured elsewhere than on the AP itself. >>> >>> On Fri, 17 Apr 2020 at 20:16, e9hack <e9h...@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> the configuration files for hostapd (/var/run/hostapd-phyX.conf) are >>>> readable for everyone. This means everyone can read the wifi passwords. If >>>> a non privileged user calls 'uci show wireless', he will also get all wifi >>>> passwords. This possible e.g. for user nobody and dnsmasq. >>>> >>>> Is this a a security issue? >>>> >>>> Regards, >>>> Hartmut >>>> >>>> _______________________________________________ >>>> openwrt-devel mailing list >>>> openwrt-devel@lists.openwrt.org >>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >>>> >>> _______________________________________________ >>> openwrt-devel mailing list >>> openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel >>> >>
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel