Project

General

Profile

Feature #887

change user/group charon-systemd runs as via strongswan.conf

Added by Noel Kuntze over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
charon-systemd
Target version:
Start date:
12.03.2015
Due date:
Estimated time:
Resolution:
Fixed

Description

Hello strongswan team,

As charon-systemd currently does not change to another user id
or drop privileges after initialisation,
it performs all operations as root user, which is not acceptable. To limit
the impact of a compromised charon-systemd daemon, I would like to limit
the privileges and directory access using systemd.

What directories does the daemon need to read or write to after initalisation?
What privileges does it need to function correctly?

Kind regards,
Noel Kuntze

Associated revisions

Revision f3c83322 (diff)
Added by Tobias Brunner over 5 years ago

charon-systemd: Add support to configure user and group via strongswan.conf

Fixes #887.

Revision 9c3c41f2 (diff)
Added by Martin Willi over 5 years ago

charon-systemd: Add missing semicolon

References #887, fixes f3c83322.

History

#1 Updated by Martin Willi over 5 years ago

  • Status changed from New to Feedback
  • Assignee set to Martin Willi

Hi Noel,

As charon-systemd currently does not change to another user id or drop privileges after initialisation,

I can't confirm that. Here user switching and capability dropping works exactly the same as with the traditional charon daemon:

# getpcaps $(pgrep charon-system)
Capabilities for `6080': = cap_net_admin,cap_net_raw+eip

In addition to configuring --with-user/group, did you pass the --with-capabilities=libcap option (see ReducedPrivileges)? If yes, does capability dropping with charon work?

What directories does the daemon need to read or write to after initalisation?

Access is not limited to specific directories, but to the user you are switching to. Usually CAP_DAC_OVERRIDE is removed from the daemon capability set, so the daemon can't bypass file permission checks.

What privileges does it need to function correctly?

This depends on your plugin configuration. It certainly needs CAP_NET_ADMIN to manage IPsec/routing, some plugins request additional capabilities during initialization (such as CAP_NET_RAW seen above).

Regards
Martin

#2 Updated by Noel Kuntze over 5 years ago

Hello Martin,

I checked the privileges with the given command line now and see, that the process has the same privileges as shown in your snippet.

I did not set

--with-user/group
, but set charon-systemd.user and charon-systemd.group in strongswan.conf
to the user and group I want charon-systemd to run as. Does your answer imply, that user switching is done by ipsec starter
and not the daemon itself? I would like to run charon-systemd as an unprivileged user with only the most
minimalistic read privileges and no write privileges. What about writing to the journal? What socket is needed for that?

You are of course correct in saying, that the necessary privileges depend on the loaded plugins.

#3 Updated by Tobias Brunner over 5 years ago

I did not set [...], but set charon-systemd.user and charon-systemd.group in strongswan.conf
to the user and group I want charon-systemd to run as.

Looks like charon-systemd did not support this yet: source:src/charon/charon.c#L162 vs. source:src/charon-systemd/charon-systemd.c@e2d9f27c19#L269
It's an easy fix though, see the associated commit.

#4 Updated by Noel Kuntze over 5 years ago

So charon-systemd can change the UID/GID when the source of 5.2.2 is patched with the associated commit?

#5 Updated by Tobias Brunner over 5 years ago

  • Tracker changed from Issue to Feature
  • Subject changed from limit privileges of charon-systemd to change user/group charon-systemd runs as via strongswan.conf
  • Category set to charon-systemd
  • Assignee changed from Martin Willi to Tobias Brunner
  • Target version set to 5.3.0
  • Resolution set to Fixed

So charon-systemd can change the UID/GID when the source of 5.2.2 is patched with the associated commit?

Yes, without the patch you'd have to use the --with-user/group configure options, as mentioned by Martin.

#6 Updated by Noel Kuntze over 5 years ago

Perfect. Now, how are credentials loaded with swanctl/ipsec? Is charon(-systemd) just told
to load the credentials at the given location or do the tools handle the loading?
Doing it the latter way would be quite convenient, as that would enable
users to deny read access to the directories and files where the said credentials are stored.

#7 Updated by Tobias Brunner over 5 years ago

Now, how are credentials loaded with swanctl/ipsec? Is charon(-systemd) just told
to load the credentials at the given location or do the tools handle the loading?

swanctl loads the credentials and sends them over the vici socket using load-cert, load-key and load-shared messages. With ipsec/stroke that's different, there the stroke plugin will parse ipsec.secrets and load the credentials when the daemon starts, end-entity certificates are loaded when the configs are added via stroke socket by starter.

#8 Updated by Noel Kuntze over 5 years ago

Okay, and what about the ipsec tool?

#9 Updated by Noel Kuntze over 5 years ago

I just tried to compile the 5.2.2 sources with the fix and it doesn't work:

make[3]: Entering directory '/home/thermi/aur/PKGBUILDs/strongswan-thermi/src/strongswan-5.2.2/src/charon-systemd'
gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/libstrongswan -I../../src/libhydra -I../../src/libcharon   -DPLUGINS=\""test-vectors aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl af-alg fips-prf gmp xcbc cmac hmac ctr ccm gcm ntru curl sqlite attr attr-sql load-tester kernel-libipsec kernel-netlink resolve socket-default farp stroke vici sql updown eap-identity eap-sim eap-sim-file eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-radius xauth-generic xauth-eap xauth-noauth dhcp ha ext-auth unity\"" -D_FORTIFY_SOURCE=2  -march=native -mtune=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -g -fvar-tracking-assignments -g -fvar-tracking-assignments -include /home/thermi/aur/PKGBUILDs/strongswan-thermi/src/strongswan-5.2.2/config.h -MT charon_systemd-charon-systemd.o -MD -MP -MF .deps/charon_systemd-charon-systemd.Tpo -c -o charon_systemd-charon-systemd.o `test -f 'charon-systemd.c' || echo './'`charon-systemd.c
distcc[16773] ERROR: compile (null) on localhost failed
charon-systemd.c: In function 'lookup_uid_gid':
charon-systemd.c:284:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'name'
  name = lib->settings->get_str(lib->settings, "%s.user", IPSEC_USER,
  ^
charon-systemd.c:284:2: error: 'name' undeclared (first use in this function)
charon-systemd.c:284:2: note: each undeclared identifier is reported only once for each function it appears in
Makefile:535: recipe for target 'charon_systemd-charon-systemd.o' failed
make[3]: *** [charon_systemd-charon-systemd.o] Error 1
make[3]: Leaving directory '/home/thermi/aur/PKGBUILDs/strongswan-thermi/src/strongswan-5.2.2/src/charon-systemd'
Makefile:498: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/thermi/aur/PKGBUILDs/strongswan-thermi/src/strongswan-5.2.2/src'
Makefile:560: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/thermi/aur/PKGBUILDs/strongswan-thermi/src/strongswan-5.2.2'
Makefile:468: recipe for target 'all' failed
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

I made it with the recipe at https://github.com/Thermi/PKGBUILDs/blob/master/strongswan/PKGBUILD

#10 Updated by Martin Willi over 5 years ago

Noel,

The patch misses a semicolon. Fixed with the referenced commit.

Regards
Martin

#11 Updated by Tobias Brunner over 5 years ago

Aw, sorry about that. Wasn't able to compile with --enable-systemd on Ubuntu 14.04.

#12 Updated by Noel Kuntze over 5 years ago

Works as expected now and changes the UID. Thanks.

#13 Updated by Tobias Brunner over 5 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF