Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Kea - root privileges and security ? (Chaigneau, Nicolas)
2. Re: Kea - root privileges and security ? (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Thu, 1 Oct 2015 15:13:13 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Kea - root privileges and security ?
Message-ID:
<ab94b0b675bdf14189cd5a861db36c842c4c1...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello guys,
It has been pointed out to me that Kea being executed with root privileges
might cause security vulnerabilities.
I believe this to be a valid concern, but I'm not sure if there is much we can
do about this.
I understand that a DHCP server needs root privileges for a number of actions:
to open / use raw sockets, bind on privileged ports 67 / 68, and maybe more.
I was wondering if it could be feasible for the process to drop its root
privileges (through seteuid ?), and only restore them when it actually needs
them.
Maybe this doesn't make sense. Probably it would be complicated.
In any case, I'd like to hear your opinion on the matter. :)
For example, CMU's dhcpd (not ISC's !) seem to implement such a feature (see
"running as an unprivileged user"):
https://www.net.princeton.edu/software/dhcpd/dhcpd.8.html
(note that I don't know anything about their product, except what I've read
from their documentation)
Any thoughts ?
Regards,
Nicolas.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20151001/7caf5386/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 01 Oct 2015 15:44:07 +0000
From: Francis Dupont <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Kea - root privileges and security ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
"Chaigneau, Nicolas" writes:
> It has been pointed out to me that Kea being executed with root privileges =
> might cause security vulnerabilities.
> I believe this to be a valid concern, but I'm not sure if there is much we =
> can do about this.
>
> I understand that a DHCP server needs root privileges for a number of actio=
> ns: to open / use raw sockets, bind on privileged ports 67 / 68, and maybe =
> more.
=> yes, a DHCP server must have privileges at least at startup.
> I was wondering if it could be feasible for the process to drop its root pr=
> ivileges (through seteuid ?), and only restore them when it actually needs =
> them.
=> it is possible to drop them but not to restore them (if you can restore
a privilege it was not really dropped).
> Maybe this doesn't make sense. Probably it would be complicated.
> In any case, I'd like to hear your opinion on the matter. :)
=> there are some attempts for a finer privilege control than root user
but IMHO they are more for a shared computer than what we have
(and only have in the future), i.e., a dedicated virtual machine.
So my opinion is that there are a lot of better places where one
should put money and/or man power to improve the security.
> For example, CMU's dhcpd (not ISC's !) seem to implement such a feature (se=
> e "running as an unprivileged user"):
> https://www.net.princeton.edu/software/dhcpd/dhcpd.8.html
> (note that I don't know anything about their product, except what I've read=
> from their documentation)
=> it is not a real security feature because of:
"Note that while this feature makes it less convenient to exploit the
server's root privileges if there are any bugs present in the server,
it does not provide complete protection, since the server still retains
a real uid of root."
in fact it is more a measure to limit side effects of bugs.
Regards
Francis Dupont <[email protected]>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 19, Issue 1
**************************************
