Re: Unprivileged default user for "tiny" daemons?

From: Shawn Webb <shawn.webb_at_hardenedbsd.org>
Date: Tue, 09 May 2023 15:16:38 UTC
On Tue, May 09, 2023 at 10:26:27AM +0200, Felix Palmen wrote:
> * Brooks Davis <brooks@freebsd.org> [20230509 08:11]:
> > On Tue, May 09, 2023 at 10:05:15AM +0200, Felix Palmen wrote:
> > > * Felix Palmen <zirias@FreeBSD.org> [20230508 18:39]:
> > > So, takeaway is: There is no safe choice other than allocating a
> > > dedicated UID for every single daemon, even if it doesn't need to
> > > own/access any files? Is this really correct?
> > 
> > This is clearly the right choice even it's a bit of a pain.
> 
> Thanks for confirming. Well, my concern wasn't the hassle to actually do
> that, but more the confusion created by the comment on top of UIDs, and
> also the fact that this seems to be a "waste" of precious "uid space"
> below 1000 if you don't need any file permissions...

Hey Felix,

Is there a reason to use a UID below 1000? Why not let `pw` set the
UID/GID for you upon creation of the account?

But, in reality, having one account per daemon is preferred,
regardless of *intentional* use of resources like filesystems,
networks, hardware, etc.

Having too many "widgets" running under a single UID/GID creates a
large attack surface. Let's hypothetically say a system has 30
(thirty) unrelated daemons running as the same UID. An attacker has
equal access to all thirty daemons upon compromising a single one.

Dedicating a UID/GID to each daemon limits what an attacker can do,
not just from a filesystems perspective, but from the perspective of
other resources, too. One must rememder that debugging facilities like
PTrace and procfs exist and can be (and are) abused for
post-exploitation activities.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc