[RFE] pesign.service: run as separate user

[dvzrv]

Hi! I'm currently maintaining pesign for Arch Linux.

When taking over the package from my predecessor I started to wonder about the pesign.service setup.
In its current state it is not possible to enable the service (#50) and its stdout/stderr is not sent to the journal (#49).

More puzzling for me is the pesign-authorize script though, as it sets ACLs

pesign/src/pesign-authorize

Lines 31 to 48 in cbc37d9

	update_subdir() {
	subdir=$1 && shift
	setfacl -bk "${subdir}"
	setfacl "${dirusers[@]}" "${dirgroups[@]}" "${subdir}"
	for x in "${subdir}"* ; do
	if [ -d "${x}" ]; then
	setfacl -bk ${x}
	setfacl "${dirusers[@]}" "${dirgroups[@]}" ${x}
	update_subdir "${x}/"
	elif [ -e "${x}" ]; then
	setfacl -bk ${x}
	setfacl "${fileusers[@]}" "${filegroups[@]}" ${x}
	else
	:;
	fi
	done
	}

for arbitrary users

pesign/src/pesign-authorize

Line 15 in cbc37d9

for user in $(cat /etc/pesign/users); do

and groups

pesign/src/pesign-authorize

Line 24 in cbc37d9

for group in $(cat /etc/pesign/groups); do

on the runtime dir and config dir

pesign/src/pesign-authorize

Lines 50 to 55 in cbc37d9

	for x in /var/run/pesign/ /etc/pki/pesign*/ ; do
	if [ -d "${x}" ]; then
	update_subdir "${x}"
	else
	:;
	fi

This introduces the two following culprits:

• pesign.service can not be run as a non-root user
• users (or users in specific groups) can add more users or groups to the allowed set of users or groups (due to the /etc/pki/pesign*/ match) (whoops, those are set in /etc/pesign/)

From a security perspective this is rather suboptimal.

Maybe I'm not understanding the specific use-cases that you had in mind when creating the service, but in its current state it does not make sense for me to package the configuration files or the service, but rather to create a service file myself.

When looking at this from a classic sysadmin perspective, I'd assume that I would create a system user/group that runs the service and that I then either add any user of a system to said group to have access to what the service creates and that I optionally have a socket unit, that gives access to the socket, that the service creates/uses if this is a requirement for e.g. pesign-client (the latter is seemingly discussed in another context in #35).

Any suggestions or explanations in regards to my assumptions would be highly appreciated! :)

[dvzrv]

As a follow up, I was looking into the code-base (again, my understanding of this service might be insufficient) and found, that daemon.c prevents itself from being started by non-root users:

pesign/src/daemon.c

Lines 1162 to 1165 in cbc37d9

	if (getuid() != 0) {
	fprintf(stderr, "pesignd must be started as root");
	exit(1);
	}

Was this design choice made due to a specific reason as to how code-signing is implemented, or could this be changed to actually allow non-root system users to run pesign.service?

[vathpela]

Was this design choice made due to a specific reason as to how code-signing is implemented, or could this be changed to actually allow non-root system users to run pesign.service?

I don't know any reason it couldn't be made to run as a non-root user. As to your first question - possibly just splitting the acl-setting out as its own one-shot service would work? The specific thing the daemon was built for was to provide a socket to talk to that could be bind-mounted into a chroot being used by builders, without having to plumb in all that's needed to do pkcs11 HSM hardware access with more than one chroot at a time.

I probably should have used (or made) some kind of pkcs11 proxy service instead.