You'd be better to ask this on tech@ not ports.
Daemons like Dovecot aren't comparable as they don't use pledge which
significantly changes what's possible.
On 2019/11/19 19:03, Tim Kuijsten wrote:
> > Looking in sample config,
> >
> > : # pick an unprivileged user/id
> > : user 1109
> >
> > Please use @newuser/@newgroup in pkg/PLIST to add a user and set the sample
> > config to use it. For the actual number, pick the next available uid from
> > ports/infrastructure/db/user.list and include a diff to add to that file
> > too.
>
> I have some questions about the optimal number of users with regard to
> privilege separation and the different processes of my program. I hope it's ok
> to ask about it here, if not, please let me know.
>
> Background about the [design]:
> In wiresep I have three types of processes, an untrusted and insignificant
> proxy (pledge("stdio", "")), a fully trusted enclave (pledge("stdio", "")),
> and a semi-trusted ifn process (pledge("stdio inet", "")). There is always
> exactly one instance of the proxy and one instance of the enclave process, but
> there can be more than one ifn process. One per configured tunnel interface.
>
> Threat model:
> If the enclave is exploited, long term secrets leak and we're hosed. It should
> be fairly easy to audit the 1300+ LoC of enclave.c and get some sense about
> the risk whether or not this will happen one day.
> (about the LoC: cc -E enclave.c | wc -l = 6214)
>
> Then the process per tunnel interface, "ifn". This is where most complexity
> goes and what touches the decrypted plain text network packets. This process
> only has short term session keys and the idea is that if someone manages to
> exploit one "ifn" process it won't be able to read/write packets of any other
> "ifn" process not access the long term secrets. (but yes, all packets with all
> peers on that single exploited interface might leak/be manipulated)
>
> Questions:
> 1a. Can one process that pledged ("stdio inet", "") somehow access/directly
> influence other processes that run by the same user id? I only know of
> ptrace(2) and both because of pledge and because none of the mentioned
> processes are descendants of each other it should be safe as long as
> kern.global_ptrace=0, which currently is the default.
>
> 1b. In the case of wiresep, if one ifn process gets exploited, would other ifn
> processes be protected from the exploited one if the user ids are different
> from each other, and is a different user id really needed for that protection?
> Of course it ultimately depends on the integrity of the IPC and shared
> resources, about the last I can say, apart from the host, only the proxy and
> enclave are shared between all ifn processes and only through a tightly
> defined IPC (see [design] and wireprot.h if you're interested).
>
> 1c. And lastly, would it be advantageous to run the enclave under a separate
> userid than the other processes? (I do that in my setup to be cautious, but
> I'm not sure if it's really beneficial to the overall security)
>
> I know most daemons simply use one separate user, but i.e. Dovecot uses one
> dovecot user and one separate dovenull user for all the login processes. Also
> smtpd has two user ids. So I'm not quite sure which one to pick from "one user
> per program" vs "one user per type of process/security domain" vs "one user
> per actual process".
>
> Thanks,
>
> Tim
>
> [design] https://github.com/timkuijsten/wiresep/blob/master/doc/design.md
