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