Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 11:10, David Lang wrote:

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance
impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was
talked about, you can just declare which ports are allowed.


tightly configured in expert hands, you are right. However, that's not
the normal user of LEDE/OpenWRT. For what (little) it's worth, I'll
point out that if home users are familar with Linux, the odds are good
that it's a flavor of Ubuntu that uses AA rather than Fedora that uses
SELinux. (not worth much because the home user probably hasn't touched
AA or SELinux)


That should not be an argument to do one or the other.
You should ask yourself how far you would want to go in securing a router. 
Personally, I would absolutely love a router with a tight SELinux policy 
since it protects me well from unsavory access from the outside.




do all the compressed filesystems support the tagging needed by SELinux?
what about external drives with FAT* or NTFS?


FAT and NTFS do not support it AFAIK, but how is that a problem?
You'd run SELinux on your internal filesystem.


it's not uncommon for people to attach an external drive for more space, and 
then have stuff run off of that drive.


If SELinux can't find the appropriate labels, does it deny or allow by default.

One of the things that annoys me about SELinux is the fact that a daemon can 
behave differently depending on if it's started by init, or started by the root 
user. I've fielded a lot of problem reports because something worked fine when 
they tested it as root and then failed when init started the process (also as 
uid 0). I've also seen cases where the testing as root created a file/directory 
with a label that isn't allowed when the process is started by init, so they 
have to detect the problem and remove the file to let it be created in the 
correct context.


For the compressed filesystems: I don't know, they will probably support it 
if they're good citizen Linux filesystems.


not all linux filesystems support xattrs.





How do you handle the possible need to re-label your files on a
read-only filesystem?



Don't know, but take a look at Android, it has SELinux enabled in enforcing 
mode (the strongest mode).


android devices tend to have a lot more storage/ram than many routers. They also 
aren't running on read-only filesystems.



what is the difference in kernel size (and tool size) between AA and
SELinux?





Don't know.


For clarity (and for weaseling out): I read a snip of the discussion and 
wanted to offer another alternative, so that the discussion could consider 
it.


And I think it's a good thing to bring up and discuss. I happen to dislike 
SELinux and would not have brought up AppArmor until after things were moved to 
not run as root in the first place. But I think it's a good discussion to have.


I am not trying to shout you down, just raising concerns.

David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[Ferry Huberts]

On 18/05/16 11:10, David Lang wrote:

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance
impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was
talked about, you can just declare which ports are allowed.


tightly configured in expert hands, you are right. However, that's not
the normal user of LEDE/OpenWRT. For what (little) it's worth, I'll
point out that if home users are familar with Linux, the odds are good
that it's a flavor of Ubuntu that uses AA rather than Fedora that uses
SELinux. (not worth much because the home user probably hasn't touched
AA or SELinux)


That should not be an argument to do one or the other.
You should ask yourself how far you would want to go in securing a 
router. Personally, I would absolutely love a router with a tight 
SELinux policy since it protects me well from unsavory access from the 
outside.




do all the compressed filesystems support the tagging needed by SELinux?
what about external drives with FAT* or NTFS?


FAT and NTFS do not support it AFAIK, but how is that a problem?
You'd run SELinux on your internal filesystem.

For the compressed filesystems: I don't know, they will probably support 
it if they're good citizen Linux filesystems.





How do you handle the possible need to re-label your files on a
read-only filesystem?



Don't know, but take a look at Android, it has SELinux enabled in 
enforcing mode (the strongest mode).




what is the difference in kernel size (and tool size) between AA and
SELinux?





Don't know.


For clarity (and for weaseling out): I read a snip of the discussion and 
wanted to offer another alternative, so that the discussion could 
consider it.




--
Ferry Huberts

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[Radu Anghel]

Replying to myself :)

On Wed, May 18, 2016 at 10:53 AM, Radu Anghel  wrote:
>
> step 1. add users to /etc/passwd (in the pre/post-install script
> probably, trying to use same uid/gid as major distributions would be
> nice)
> step 2. add config option for user/group in the relevant /etc/config/ file
> step 3. modify startup script to use the user/group options when
> generating daemon config file
> step 4. ???
> step 5. PROFIT!
>

This approach would also open up some interesting posibilities
(interesting for me at least) like the ability to add non-privileged
users that can perform configuration changes or backups but can't use
sysupgrade.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was talked 
about, you can just declare which ports are allowed.


tightly configured in expert hands, you are right. However, that's not the 
normal user of LEDE/OpenWRT. For what (little) it's worth, I'll point out that 
if home users are familar with Linux, the odds are good that it's a flavor of 
Ubuntu that uses AA rather than Fedora that uses SELinux. (not worth much 
because the home user probably hasn't touched AA or SELinux)


do all the compressed filesystems support the tagging needed by SELinux? what 
about external drives with FAT* or NTFS?


How do you handle the possible need to re-label your files on a read-only 
filesystem?


what is the difference in kernel size (and tool size) between AA and SELinux?

David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[Radu Anghel]

On Wed, May 18, 2016 at 9:25 AM, John Crispin  wrote:
>
> to elaborate, imagine dnsmasq running inside a jailm where ut only
> thinks it is root but is not in reality. also ld-preloading bind and
> connect would allow us to do pretty adavnced stuff like only allowing
> dnsmasq to open certain ports. essentially an acl around the
> bind/connect calls.
>

Doing this with a in-house developed daemon would introduce another
SPOF in the same way as running everyting with the same non-root user.
Imagine a security issue in such a daemon, it would affect *all*
daemons running through it.

This would also duplicate existing functionality (the code for
dropping privileges to a preconfigured user already exists in most
daemons, it is compiled as there is no --without-privileges-code
./configure option). Implementing different users with this approach
can be done in a few easy steps with minor to none added overhead:

step 1. add users to /etc/passwd (in the pre/post-install script
probably, trying to use same uid/gid as major distributions would be
nice)
step 2. add config option for user/group in the relevant /etc/config/ file
step 3. modify startup script to use the user/group options when
generating daemon config file
step 4. ???
step 5. PROFIT!

I understand there are trust issues about this functionality (don't
trust that the daemon really dropped all privileges), in such a case I
would use SELinux. SELinux can be enabled as "permissive" until a
proper policy is created for everything.

There are other things to consider also, because this is supposed to
run on embedded devices with as low as 4M flash space:

- SELinux would increase kernel size, thus making it hard to fit
inside the flash, or even bigger than the fixed kernel partition for
some devices.
- jails, containers and other options discussed require more
memory/CPU/flash space than is probably available on said devices.


Radu

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[Ferry Huberts]

On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



On 18/05/16 09:25, John Crispin wrote:



On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin 
wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between
until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.




You might just as well switch on SELinux and use the policies that are
already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was talked 
about, you can just declare which ports are allowed.




SELinux configs that Fedora uses have to be so permissive to keep from
breaking too many 'normal' use cases that I really question how valuable
they are.


And this is based on what exactly?
I've been using Fedora ever since SELinux was first enabled and I don't 
see that. Processes are well secured.
If you think about stuff like Firefox, then ok, that one is really hard 
to secure, better run it in a sandbox.

But process that are well-defined in behaviour are well secured.





A SELinux system tuned by an expert is going to be more secure than an
AppArmor system tuned by an expert, SELinux just can do more (at least
right now). But there aren't many experts of that caliber around. A
reasonably competent sysadmin can understand an AppArmor config and
tweak it for their layout without too much effort (once they identify
that AppArmor is blocking what they are trying to do)




Agreed, it is a balance.

However, I must note that I've encountered very few cases where the 
policy had to be tweaked, on my laptops, desktop and most of all servers.


One example of tweaking is when I move a service to a different port.
That is a single command, like (moving the port of the 'cockpit' service):

semanage port -a -t websm_port_t -p tcp "$newport"




My 2 cents :-)






David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


--
Ferry Huberts

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



On 18/05/16 09:25, John Crispin wrote:



On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.




You might just as well switch on SELinux and use the policies that are
already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full
blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between different 
application configs that you do with SELinux, so you can focus on the specific 
application that you are concerned about.


SELinux configs that Fedora uses have to be so permissive to keep from breaking 
too many 'normal' use cases that I really question how valuable they are.


A SELinux system tuned by an expert is going to be more secure than an AppArmor 
system tuned by an expert, SELinux just can do more (at least right now). But 
there aren't many experts of that caliber around. A reasonably competent 
sysadmin can understand an AppArmor config and tweak it for their layout without 
too much effort (once they identify that AppArmor is blocking what they are 
trying to do)


David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.


well, between the different namespace options (pid, user, network, filesystem) 
you can have the thing running in the container thinking that it is root and the 
container configuration limit what it can do. This is the bleeding edge of 
containerization, so advanced use cases like you are defining are going to be 
fragile as the kinks get worked out. But there are a lot of people working in 
this problem space right now.


I personally think that the best bet is to ignore the problem for now, but keep 
an eye on the different container projects, try to make them all work on LEDE, 
and as the dust starts to settle, pick the top (or top few) survivors and start 
using them.


Right now some of the namespace types open up as many vulnerabilities as they 
allow you to close.




Another think to keep in mind is that most of these projects allow you to 
package up and containerize individual daemons, but as soon as you start needing 
to have the different things interact with each other (say the container running 
LUCI needs to start configuring the container running asterisk), they get really 
ugly.




And finally, many of the people focusing on these projects are aiming for the 
cloud datacenter market where every machine is ephemeral and is expected to 
disappear and take all data/configs stored on it as it goes. So they all rely on 
some external storage/database setup to hold all that stuff. Not something 
normally available to LEDE type devices running in homes and small offices.



David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 09:49, Etienne Champetier wrote:
> Hi,
> 
> 2016-05-18 9:25 GMT+02:00 John Crispin :
>>
>>
>> On 18/05/2016 09:21, Radu Anghel wrote:
>>> /* sending again because i hit 'reply' instead of 'reply all' :) */
>>>
>>> On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:

 ok, there had been some discussion about building a super daemon that
 runs, then ld-preloading bind() and co and using ubus to transport
 sockets around. using caps or /proc sounds like a good i between until
 such a daemon exists

>>>
>>> Most daemons I know of that need to bind to ports <1024 start as root
>>> and after binding to the port they drop privileges to the privileges
>>> of the user specified in their config file. For those daemons just
>>> adding a user and specifying it in their config file should be enough.
>>> For the daemons that don't need to bind to <1024 just starting them
>>> from their own user account is ok as they don't need additional
>>> privileges.
>>>
>>> For example the dnsmasq daemon has these options:
>>>
>>> # If you want dnsmasq to change uid and gid to something other
>>> # than the default, edit the following lines.
>>> #user=
>>> #group=
>>>
>>> I don't think that integrating such functionality in ubus or some
>>> other LEDE-only super-daemon is a good idea. Config options +
>>> capabilities for those daemons withut such options is a good way of
>>> doing this in my opinion. Also use different users for different
>>> daemons, as others said.
>>
>> to elaborate, imagine dnsmasq running inside a jailm where ut only
>> thinks it is root but is not in reality. also ld-preloading bind and
>> connect would allow us to do pretty adavnced stuff like only allowing
>> dnsmasq to open certain ports. essentially an acl around the
>> bind/connect calls.
>>
>> John
>>
> 
> Capabilities is the way to go.
> Filesystem capabilities are painfull, so we will use process
> capabilities (inherited from procd).
> 
> I've already integrated normal capabilities in ujail, so you can run
> as "reduced" root.
> 
> You can inherit capabilities between non root user (if you have
> capabilities to inherit...) but the program as to do it explicitly,
> so for exemple i could (not yet supported) launch zabbix with
> CAP_NET_RAW and user zabbix, but subprocess of zabbix will not be able
> to use it.
> 
> For subprocess to inherit capabilities without using root user, we
> need to look into ambient capabilities (linux 4.3)
> 
> Cheers
> Etienne
> 

Hi Etienne,

i agree, for now this should be handled via caps. never heard of ambient
ones, will look into that. thanks for the pointer.

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 09:46, Ferry Huberts wrote:
> 
> 
> On 18/05/16 09:25, John Crispin wrote:
>>
>>
>> On 18/05/2016 09:21, Radu Anghel wrote:
>>> /* sending again because i hit 'reply' instead of 'reply all' :) */
>>>
>>> On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:

 ok, there had been some discussion about building a super daemon that
 runs, then ld-preloading bind() and co and using ubus to transport
 sockets around. using caps or /proc sounds like a good i between until
 such a daemon exists

>>>
>>> Most daemons I know of that need to bind to ports <1024 start as root
>>> and after binding to the port they drop privileges to the privileges
>>> of the user specified in their config file. For those daemons just
>>> adding a user and specifying it in their config file should be enough.
>>> For the daemons that don't need to bind to <1024 just starting them
>>> from their own user account is ok as they don't need additional
>>> privileges.
>>>
>>> For example the dnsmasq daemon has these options:
>>>
>>> # If you want dnsmasq to change uid and gid to something other
>>> # than the default, edit the following lines.
>>> #user=
>>> #group=
>>>
>>> I don't think that integrating such functionality in ubus or some
>>> other LEDE-only super-daemon is a good idea. Config options +
>>> capabilities for those daemons withut such options is a good way of
>>> doing this in my opinion. Also use different users for different
>>> daemons, as others said.
>>
>> to elaborate, imagine dnsmasq running inside a jailm where ut only
>> thinks it is root but is not in reality. also ld-preloading bind and
>> connect would allow us to do pretty adavnced stuff like only allowing
>> dnsmasq to open certain ports. essentially an acl around the
>> bind/connect calls.
>>
> 
> 
> You might just as well switch on SELinux and use the policies that are
> already in-place in Fedora and RedHat/CentOS.
> 
> You then get even stronger protection and run-time performance impact is
> negligible.
> 
the stuff i proposed has not runtime hit. selinux is simple to full
blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[Etienne Champetier]

Hi,

2016-05-18 9:25 GMT+02:00 John Crispin :
>
>
> On 18/05/2016 09:21, Radu Anghel wrote:
>> /* sending again because i hit 'reply' instead of 'reply all' :) */
>>
>> On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:
>>>
>>> ok, there had been some discussion about building a super daemon that
>>> runs, then ld-preloading bind() and co and using ubus to transport
>>> sockets around. using caps or /proc sounds like a good i between until
>>> such a daemon exists
>>>
>>
>> Most daemons I know of that need to bind to ports <1024 start as root
>> and after binding to the port they drop privileges to the privileges
>> of the user specified in their config file. For those daemons just
>> adding a user and specifying it in their config file should be enough.
>> For the daemons that don't need to bind to <1024 just starting them
>> from their own user account is ok as they don't need additional
>> privileges.
>>
>> For example the dnsmasq daemon has these options:
>>
>> # If you want dnsmasq to change uid and gid to something other
>> # than the default, edit the following lines.
>> #user=
>> #group=
>>
>> I don't think that integrating such functionality in ubus or some
>> other LEDE-only super-daemon is a good idea. Config options +
>> capabilities for those daemons withut such options is a good way of
>> doing this in my opinion. Also use different users for different
>> daemons, as others said.
>
> to elaborate, imagine dnsmasq running inside a jailm where ut only
> thinks it is root but is not in reality. also ld-preloading bind and
> connect would allow us to do pretty adavnced stuff like only allowing
> dnsmasq to open certain ports. essentially an acl around the
> bind/connect calls.
>
> John
>

Capabilities is the way to go.
Filesystem capabilities are painfull, so we will use process
capabilities (inherited from procd).

I've already integrated normal capabilities in ujail, so you can run
as "reduced" root.

You can inherit capabilities between non root user (if you have
capabilities to inherit...) but the program as to do it explicitly,
so for exemple i could (not yet supported) launch zabbix with
CAP_NET_RAW and user zabbix, but subprocess of zabbix will not be able
to use it.

For subprocess to inherit capabilities without using root user, we
need to look into ambient capabilities (linux 4.3)

Cheers
Etienne

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[Ferry Huberts]

On 18/05/16 09:25, John Crispin wrote:



On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin  wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.




You might just as well switch on SELinux and use the policies that are 
already in-place in Fedora and RedHat/CentOS.


You then get even stronger protection and run-time performance impact is 
negligible.




John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



--
Ferry Huberts

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 09:04, David Lang wrote:
> 
> The first question I would have is if we are going to the system users
> in an essentially random order (as needed so two systems with the same
> packages installed in a different order have different user->uid
> mapping) or if we are going to define service accounts distro wide so
> they are always going to be the same.


what would be the pros and cons for either of those ?

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 08:09, Daniel Curran-Dickinson wrote:

On 16-05-18 01:05 AM, John Crispin wrote:

Hi,

we had previously started building the infra for running stuff as !root.
so far we have added

* the userid/gid stuff
* acl on ubus

things that i know are missing

* handling network ports < 1024

what am i missing ? can anyone think of other issues we need to address
before we change uid to !root ?



Er, do you mean uid of procd or ubus or everything?  I'm not sure we're
clear on which uid you mean?


ok, my mail that sounded totally obvious to me apparently was hard to
understand.

right now we run $everything as root which is obviously rather daring so
we need to change it to what normal distros do and run stuff as their
own users wherever it makes sense and give those users only the
permissions required.


Ok, that makes a lot of sense. The good news here is that we don't have to start 
off with doing fancy stuff like passing sockets around, playing with 
capabilities to bind to low ports, SELinux/AppArmor, etc. We can start off by 
just copying the sysV init configs that have existed for other distros.


Most of the work is actually going to be in undoing OpenWRT specific configs 
that run everything as root and fall more in line with what the other distros 
are doing.


The first question I would have is if we are going to the system users in an 
essentially random order (as needed so two systems with the same packages 
installed in a different order have different user->uid mapping) or if we are 
going to define service accounts distro wide so they are always going to be the 
same.


David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 08:09, Daniel Curran-Dickinson wrote:
> On 16-05-18 01:05 AM, John Crispin wrote:
>> Hi,
>>
>> we had previously started building the infra for running stuff as !root.
>> so far we have added
>>
>> * the userid/gid stuff
>> * acl on ubus
>>
>> things that i know are missing
>>
>> * handling network ports < 1024
>>
>> what am i missing ? can anyone think of other issues we need to address
>> before we change uid to !root ?
>>
> 
> Er, do you mean uid of procd or ubus or everything?  I'm not sure we're
> clear on which uid you mean?

ok, my mail that sounded totally obvious to me apparently was hard to
understand.

right now we run $everything as root which is obviously rather daring so
we need to change it to what normal distros do and run stuff as their
own users wherever it makes sense and give those users only the
permissions required.

John

> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[John Crispin]

On 18/05/2016 08:08, David Lang wrote:
> On Wed, 18 May 2016, John Crispin wrote:
> 
>> Hi,
>>
>> we had previously started building the infra for running stuff as !root.
>> so far we have added
>>
>> * the userid/gid stuff
>> * acl on ubus
>>
>> things that i know are missing
>>
>> * handling network ports < 1024
>>
>> what am i missing ? can anyone think of other issues we need to address
>> before we change uid to !root ?
> 
> what things are you trying to run as !root?

services and daemons obviously

> just changing everything to run as user lede (uid 1) instead of root
> (uid 0) doesn't actually buy much, especially if user lede is able to
> administer things https://xkcd.com/1200/
>
> you want to end up running different types of things as different users,
> and there the permissions get more 'interesting'

thanks for the pointer, that was totally not obvious at all ...

> there is a capability you can give to binaries to let them bind to ports
> < 1024, there is also a proc setting you can use to let anything bind to
> ports < 1024.

ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists

> 
> There are various other things that will require capabilities to work
> (including some versions of ping and traceroute), but it's a matter of
> fixing them as you bump into them.

yes, but i'll try those on my journey.

> don't try to make everything run as the same !root user, migrate things
> one (or at least one category) at a time.

thanks for the pointer, that was totally not obvious at all ...

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[Daniel Curran-Dickinson]

On 16-05-18 01:05 AM, John Crispin wrote:
> Hi,
> 
> we had previously started building the infra for running stuff as !root.
> so far we have added
> 
> * the userid/gid stuff
> * acl on ubus
> 
> things that i know are missing
> 
> * handling network ports < 1024
> 
> what am i missing ? can anyone think of other issues we need to address
> before we change uid to !root ?
> 

Er, do you mean uid of procd or ubus or everything?  I'm not sure we're
clear on which uid you mean?

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


Hi,

we had previously started building the infra for running stuff as !root.
so far we have added

* the userid/gid stuff
* acl on ubus

things that i know are missing

* handling network ports < 1024

what am i missing ? can anyone think of other issues we need to address
before we change uid to !root ?


what things are you trying to run as !root?

just changing everything to run as user lede (uid 1) instead of root (uid 0) 
doesn't actually buy much, especially if user lede is able to administer things 
https://xkcd.com/1200/


you want to end up running different types of things as different users, and 
there the permissions get more 'interesting'


there is a capability you can give to binaries to let them bind to ports < 1024, 
there is also a proc setting you can use to let anything bind to ports < 1024.


There are various other things that will require capabilities to work (including 
some versions of ping and traceroute), but it's a matter of fixing them as you 
bump into them.


don't try to make everything run as the same !root user, migrate things one (or 
at least one category) at a time.


David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] running stuff as !root

[John Crispin]

Hi,

we had previously started building the infra for running stuff as !root.
so far we have added

* the userid/gid stuff
* acl on ubus

things that i know are missing

* handling network ports < 1024

what am i missing ? can anyone think of other issues we need to address
before we change uid to !root ?

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev