Re: [OpenWrt-Devel] Possible security issue
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
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 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
>> 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 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
Re: [OpenWrt-Devel] Possible security issue
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 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 > 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 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
Re: [OpenWrt-Devel] Possible security issue
>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 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 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
Re: [OpenWrt-Devel] Possible security issue
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 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] Possible security issue
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
