<div dir="ltr"><div>Maybe it should be something like:</div><div><br></div><div>```bash<br></div><div>groupadd ubus</div><div><div>for user in "root ..."; do<br></div><div> usermod -a -G ubus "${user}"</div><div>done</div><div><br></div></div><div>chgrp ubus /sbin/uci /var/run/ubus.sock</div><div>chmod g+rw /var/run/ubus.sock</div><div>chmod g+rwx /sbin/uci<br></div><div>chmod o-rwx /sbin/uci /var/run/ubus.sock</div><div>```<br></div><div><br></div><div>What would this break?</div><div><a href="https://openwrt.org/docs/techref/ubus">https://openwrt.org/docs/techref/ubus</a></div><div><br></div><div>...<br></div><div><br></div><div>Better sandboxing in procd than chroot could be an objective. IDK where the previous discussions are?<br></div><div><a href="https://openwrt.org/docs/techref/procd">https://openwrt.org/docs/techref/procd</a></div><div><br></div><div>cgroups without systemd:<br></div><div><a href="https://wiki.archlinux.org/index.php/cgroups#With_libcgroup">https://wiki.archlinux.org/index.php/cgroups#With_libcgroup</a></div><div><br></div><div>Notes re: SELinux (and containers)</div><div><a href="https://github.com/rancher/k3s/issues/1372#issuecomment-581797716">https://github.com/rancher/k3s/issues/1372#issuecomment-581797716</a><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://blog.openshift.com/securing-kubernetes/">https://blog.openshift.com/securing-kubernetes/</a><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br><br> 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.<br><br> 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.<br></blockquote></blockquote><div><br></div><div>Everybody's doing it:</div><div><a href="https://en.wikipedia.org/wiki/Seccomp#Software_using_seccomp_or_seccomp-bpf">https://en.wikipedia.org/wiki/Seccomp#Software_using_seccomp_or_seccomp-bpf</a> </div><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 18, 2020 at 10:22 PM Joel Wirāmu Pauling <<a href="mailto:joel@aenertia.net">joel@aenertia.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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. <br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">So fiddling inode bitmasks is not addressing anything IMNSHO because of that fact.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 18 Apr 2020 at 00:50, Wes Turner <<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>From a least privileges perspective:</div><div dir="auto"><br></div><div dir="auto">- chmod o-rwx /var/run/hostapd-phyX.conf</div><div dir="auto">- chmod o-x uci # setfacl? </div><div dir="auto"><br></div><div dir="auto">Compromise of a service running as a different user should not result in disclosure of sensitive keys only necessary for different services. </div><div dir="auto"><br></div><div dir="auto"><a href="https://openwrt.org/docs/guide-user/security/security-features" target="_blank">https://openwrt.org/docs/guide-user/security/security-features</a> mentions procd jail / chroot?<br></div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, Apr 17, 2020, 5:13 AM Joel Wirāmu Pauling <<a href="mailto:joel@aenertia.net" target="_blank">joel@aenertia.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">No. If you have physical access to the node and/or a valid login as Admin then any form of PSK is vulnerable. <br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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. <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 17 Apr 2020 at 20:16, e9hack <<a href="mailto:e9hack@gmail.com" rel="noreferrer" target="_blank">e9hack@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
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.<br>
<br>
Is this a a security issue?<br>
<br>
Regards,<br>
Hartmut<br>
<br>
_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org" rel="noreferrer" target="_blank">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel" rel="noreferrer noreferrer" target="_blank">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a><br>
</blockquote></div>
_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org" rel="noreferrer" target="_blank">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel" rel="noreferrer noreferrer" target="_blank">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a><br>
</blockquote></div></div></div>
</blockquote></div>
</blockquote></div>