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 <j...@phrozen.org> 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
