Low privilege users

[michel-stam]

Hey @CTassisF,

Just took a quick look at the Docker file, I only see one user being added, ripe-atlas.

The intent is to have measurements run as ripe-atlas-measurement:ripe-atlas, and the control logic (the sbin/ripe-atlas) as ripe-atlas.
Is this on your radar?

Regards,

Michel Stam

[CTassisF]

Hey @michel-stam,

Thanks for your feedback :)

From ./configure --help, it seems --with-user, --with-measurement-user, and --with-group default to ripe-atlas when undefined. I assumed measurements would run as the ripe-atlas user since /sbin/ripe-atlas is running as root in a non-privileged container, but I didn't check. Now, I see everything is running as root, likely due to --disable-chown.

I tried --enable-chown but encountered a bug during make. I will report this to RIPE-NCC/ripe-atlas-software-probe. Once fixed, I will update the code to run measurements as a low privilege user.

Best regards,
César

[michel-stam]

Hello @CTassisF.

Correct. The default is to revert to the behaviour as it was in 5080 and earlier. However, the intent with the software probes going forward is to go for a little bit more security. In fact, the anchors were already doing this for some time, this just aligns all probe forms (software, hardware or anchor) to the same scheme. Improves security and also less permutations of users (previously, root, atlas or atlas+atlasmsm) results in fewer bugs.

--enable-chown will work only if you install as root. Not sure if this was the error you saw? This is mostly meant for people installing from source.

--disable-chown effectively disables all the chown() calls (which you can't do unless you're root). However, this may be desirable for packaging, where you typically don't build packages as root. This would apply to dpkg-buildpackage, rpmbuild and OpenWRT.
If you disable chown during the build, you have to do this yourself. Examples are in the rhel/ripe-atlas-probe.spec, under the %files section. There's also bits and pieces doing this in the OpenWRT and Debian build instructions, but since these are not production-ready yet I would not recommend looking at those right now.

Regards,

Michel

[CTassisF]

Hey @michel-stam,

Thank you for the explanation. It is certainly in my interest that this project of mine follows the official RIPE implementation of software probes and other best practices.

Regarding the issue I mentioned before, I've reported it here: RIPE-NCC/ripe-atlas-software-probe#108

Best regards,
César

[CTassisF]

Hey @michel-stam,

Following the release of version 5100, which includes fixes for wrong permissions when systemd is disabled, I rebuilt this project with --enable-chown. The build completed successfully, and the measurement daemons ran fine with low-privilege users. Thank you for the new version of RIPE Atlas Software Probe.

Unfortunately, I had to roll back this change because running the measurements with low-privilege users would require extra container capabilities (probably --cap-add=NET_RAW), and some implementations, like MikroTik RouterOS Containers, don’t support adding extra capabilities. For this reason, I think it’s better to keep this project, ripe-atlas-alpine, without low-privilege users.

Best regards,
César

[michel-stam]

Hi Cesar,

in order to run with least privileges, yes, the measurement code needs to have CAP_NET_RAW.

I was able to run this on OpenWRT by leveraging ujail. Initial code in the openwrt/ directory, to give you an idea. I did have to give the ripe-atlas script those privileges too (as well as SETUID), which is not the most desirable, but I had to work within the limitations of what ujail can do.

I have no knowledge on Mikrotik I can offer to help, but maybe the container can be similarly enabled to work?

Regards,

Michel