[OpenWrt-Devel] Possible security issue

Wes Turner wes.turner at gmail.com
Sat Apr 18 23:04:43 EDT 2020

Maybe it should be something like:

groupadd ubus
for user in "root ..."; do
    usermod -a -G ubus "${user}"

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?


Better sandboxing in procd than chroot could be an objective. IDK where the
previous discussions are?

cgroups without systemd:

Notes re: SELinux (and containers)

>     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:

On Sat, Apr 18, 2020 at 10:22 PM Joel Wirāmu Pauling <joel at aenertia.net>

> 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.turner at 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 <joel at 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 <e9hack at 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 at lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200418/2caf52cd/attachment.htm>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list