Rootfull SystemD services can't run ssh-keygen, SELinux

Ask Fedora
, ,
1

Hello,

I was configuring my architecture with CoreOS, SystemD services, and Quadlet, but SELinux stopped me. I want to generate keys directly on the Host via ssh-keygen from a SystemD service, but SELinux doesn’t allow it.

I found a workaround by generating the command in a temporary container, but I’d like to know if anyone has an idea why there are restrictions on the ssh-keygen command when all I’m trying to do is generate a key pair ?

> runcon system_u:system_r:initrc_t:s0 ssh-keygen
$ runcon: ‘ssh-keygen’: Permission denied

> stat /usr/bin/ssh-keygen
$ Context: system_u:object_r:ssh_keygen_exec_t:s0

> runcon system_u:system_r:unconfined_t:s0 ssh-keygen
$ Generating public/private ed25519 key pair.

I know I could modify SELinux to get it to work directly via SystemD, but without understanding the reason for the restriction, I preferred not to touch it.

2

What were the AVC’s you received when trying to run the program?

3

Of course ! :grinning_face:

Here is the AVC denied :

AVC avc:  denied  { entrypoint } for  pid=26629 comm="runcon" path="/usr/bin/ssh-keygen" dev="overlay" ino=5404 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:ssh_keygen_exec_t:s0 tclass=file permissive=0
4

Is this the command inside the quadlet template?

6

This is not the context under which a new systemd unit will run. If you want to try to reproduce that, use systemd-run instead.

What is the reason that makes you re-generate those keys?

7

For anyone else who might encounter the same kind of problem.

I was calling upon my scripts via ExecStart=bash /etc/systemd/system/hello.sh; this was providing system_u:system_r:init_t:s0 as the security context, and this was what posed the problem.
I replaced it with ExecStart=/etc/systemd/system/hello.sh, and now everything works.

Thank @siosm you put me on the track to the solution ! :star_struck:

1 Like
8

I would recommend moving your scripts to /usr/local/bin/ instead and they would automatically get the right SELinux context.

9

Question,

Is there/would there be a way to lint systemd units looking for selinux policy violations without running the executables in the unit?

If so it would be an interesting linter tool for people customizing units, something to optionally run before deamon-reload that could warn and make suggestions.

-jef"finally got a microwave in the new apartment, I’m writing this jacked up on 2 day old microwaved coffee"spaleta

1 Like
10

Indeed, I moved everything into the corresponding folders /usr/local/{bin,etc,src,lib}.

But I should take the time to investigate how selinux works, I have basic knowledge but it blocks me too often… :worried:

11

It would be difficult. If you are writing a systemd unit, especially a system one, your are an administrator and you should know that you need to read the man pages and check the logs for errors. By default, new systemd units run mostly unconfined, so you should not have to care about SELinux, if you place things in the expected places.

1 Like