SECURITY

Security concerns
-----------------

Trust and assumptions
---------------------

Dinit does assume that most input it receives is trusted and not produced maliciously. This
includes:

- service descriptions, including service names
- "environment" file
- commands received via the control socket

Since it is trusted, Dinit will do no or minimal validation/sanitisation on these. Tools which
allow creation or modification of these inputs should do so with care. (The control socket is
treated with a little more care, in an attempt to guard against buggy or partially compromised
clients, but untrusted applications/users should *not* be granted access to the socket).

Dinit when run as system manager (naturally) also trusts and relies on the general integrity of
the system on which it runs. It cannot defend against a fully compromised system and does not
attempt to do so. It does *not* trust or rely on aspects of the system that are (or should not
be) controlled by non-administrative users. In other words, Dinit should be secure but does not
by itself aim to provide *additional system* security (except by having features to run services
more securely).

Dinit does not expect user identities to change during operation. If a service is configured to
run as user xyz, the numeric ID of user xyz may be determined when the service is loaded rather
than when the service is started. If the same ID is re-assigned to a different user, Dinit might
run the service as that other user, create logfiles owned by that other user, etc.


Specific concerns and details
-----------------------------
 
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).

Dinit service descriptions may specify output files (sockets, logfiles) and these are opened
without (or with minimal) checks. A malicious user in control of a service description could cause
arbitrary system files to be overwritten.


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.