Just make sure your processes call setresuid() or setresgid() to change
(or change to the same...) their uid or gid or gidset, which locks out
ptrace from related processes. That also kills inadvertent coredump drops.
Beyond that, you are dependent on the code not having take-over bugs which
attempt to leak information, and your information leakages are controlled
by the nature of pledge/unveil to permit new resource allocation for disclosure,
or the utilization of pre-existing resources for discosure. Naturally
the pre-existing resources become the medium for leakage.
If there's a bug which allows remote control, and if we haven't put enough
control impediments in place.
Tim Kuijsten <info+po...@netsend.nl> 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
>
