| 12345678910111213141516171819202122232425262728293031 |
- Security concerns
- -----------------
- Dinit is designed to allow control by one system user. In the case of a system instance, this is
- the root user. Of course, the unix model allows users to change identity and so regular users can
- control a system dinit instance using sudo or su, for example.
- Essential security is enforced by the system, not by Dinit itself. The socket used to control
- dinit is owned by a particular user (the user who starts dinit) and the permissions on this socket
- are set so that only the owning user can connect to the socket. According to the Linux unix(7)
- manual page, "older" BSDs do not honour socket permissions; on such systems, presumably the
- permissions on the containing directory at least are checked (so it is necessary to place the
- socket in a directory that is inaccessible to non-root users to ensure secure operation). This
- does not appear to be a concern for the various current *BSD systems that I have looked at.
- In general it should be assumed that a process that is able to open the control socket (or
- otherwise obtain an open connection to the socket) will be able to execute arbitrary code as root
- (or rather, as the user which dinit is running as). That said, errors or missing checks in the
- control protocol handling which could cause unspecified or undefined behaviour are considered a
- security concern (since they potentially allow minor flaws in clients to become arbitrary code
- execution within the dinit daemon).
- Reporting security issues
- -------------------------
- Bearing the above in mind, any security issues in Dinit should be reported via email to:
- davmac@davmac.org
-
- I will endeavour to respond promptly, but please allow a reasonable time frame before wider
- disclosure.
|
