Default use of 'less' is a security concern

[stvhay]

Submission type

• Bug report
• Request for enhancement (RFE)

NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!

systemd version the issue has been seen with

ALL

NOTE: Do not submit bug reports about anything but the two most recently released systemd versions upstream!

Used distribution

ALL

In case of bug report: Expected behaviour you didn't see

adding this to sudoers: "%manager ALL=(root) NOPASSWD: /bin/systemctl status" would not provide a path to root shell

In case of bug report: Unexpected behaviour you saw

once the pager (less) is invoked, !/bin/bash drops you to root shell.

In case of bug report: Steps to reproduce the problem

(covered above)

I realize that this can be addressed by adding the --no-pager option and creating aliases, but is sure seems like invoking a pager that lets you drop shell on a utility run as root is just begging for trouble.

[Stebalien]

That sudoers rule is begging for trouble (and less is the standard linux pager). Why exactly do you need permission to run this as root? It works just fine as a normal user.

[poettering]

Sorry, but this appears to be a limitation of your sudoers rule, but not systemctl. The auto-paging behaviour of systemctl is well-known, and can be disabled easily, including in a per-invocation mode the way you describe.

Sorry, but I don't think there's anything to fix here in systemd: the general should be to be very careful when writing sudo rules (or even better simply not use it at all).

I hope this makes sense, closing.

[stvhay]

What you are saying makes sense, but I disagree with it. Your choice.

I'll only expand on what I said by saying this. Misconfiguration is a very common root cause of security vulnerabilities in live systems. For example, it is in the OWASP Top 10 (A5). It seems like a poor design choice to invoke a pager in a utility that will be frequently run as root, and may need access marshaled to it using tools like sudo. In fact, if you Google around to see what people are doing, you can see examples of people using sudo in this way to marshal access to systemctl without disabling the pager. I would think that the systemd project would want to prevent these kinds of common misconfigurations.

I agree that 'systemctl status' is not the best example, given that is works pretty much fully intact as root. That said, I've seen cases where status output varies a bit depending on level of access. In my own experience, I run systemctl status dhcpd.service as root, because doing it this way gives me a short tail of the dhcp log. Doing it as a user does not. There's enough lines there to invoke a pager, and now we have a potential path to root.

I also will concede that in this case, the best practice is to lock down the environment better. This can be done in sudoers. It is not difficult to create an environment for systemctl that will not invoke a pager. I just think its something that a lot of people are going to miss, and it seems like default behavior that is just asking for trouble.

[Stebalien]

This is literally why policykit was invented. Allowing untrusted users to run interactive applications as root is just begging for trouble. If you, for example, need to allow a user start/stop a specific service, you can add a policykit rule to allow then to do so without allowing anyone to run systemctl as root.

because doing it this way gives me a short tail of the dhcp log

Add yourself to the systemd-journal group.

This can be done in sudoers. It is not difficult to create an environment for systemctl that will not invoke a pager.

You can also set the LESSSECURE environment variable to 1 (but make sure that the user can't reset it). See the less(1) manual for details. Unfortunately, I don't know of a way to automatically set this variable for all NOPASSWD sudoers entries. Regardless, I'd still argue that this is a "bad idea".

[robmv]

As the original submitter of the bug on Red Hat's bugzilla, I have seen these sudo "misconfigurations" too much. You can't ask for people to know exactly what other processes are invoked when you use a tool like systemctl.

The user that installed the sudo rule could have tried it on a 20" monitor and never saw that a pager was activated, so it has no idea a pager needs to be disabled, then goes and writes a tool for less privileged IT staff that use systemctl status, and then some of those notice the pager is active because they are using a small monitor / window and take advantage of the less feature to invoke programs.

IMHO LESSSECURE should be added to all less invocations by systemd, and by the way, never use more as a fallback because it doesn't have a way to disable program invocation

[robmv]

This is literally why policykit was invented. Allowing untrusted users to run interactive applications as root is just begging for trouble. If you, for example, need to allow a user start/stop a specific service, you can add a policykit rule to allow then to do so without allowing anyone to run systemctl as root.

policykit is an overkill for a sysadmin that just want to give their IT staff a tool to check if a system is running or not via sudo.

[poettering]

IMHO LESSSECURE should be added to all less invocations by systemd, and by the way, never use more as a fallback because it doesn't have a way to disable program invocation

That makes sense I guess. Can you file an RFE about exactly this?

[poettering]

policykit is an overkill for a sysadmin that just want to give their IT staff a tool to check if a system is running or not via sudo.

You don't need privs to check that... You only need privs if you actually want to change state of something, introspection of the objects systemd manages is unrestricted.

[poettering]

That makes sense I guess. Can you file an RFE about exactly this?

Or even better file a PR that adds that?

[robmv]

Or even better file a PR that adds that?

Cloning right now, it will probably take more time for me to learn the testing infrastructure.

[poettering]

@robmv hmm, so i figure it's quicker if i just prep the PR for that, please see #16916.

[vcaputo]

I think the automagic pager invocation is just a misfeature plain and simple. The tools should just print to stdout, and a caller may redirect stdout into a pager if they wanted one.

If it weren't launching the pager from the privileged context during this magic, we wouldn't be having this discussion. There's zero security problem when the user pipes stdout of sudo into a pager.

[topimiettinen]

systemctl and other tools should allow (opt-in/opt-out) fully sandboxing the helper applications. I know the life cycle is not expected to be long for udevd helpers, but it could still be an opt-in feature. In this specific case, less should not have any need for capabilities (Capabilities=), network access (IPAddressDeny=, RestrictAddressFamilies=), writable or even accessible ABIFS (InaccessiblePaths=/sys /proc, MountAPIVFS=no etc), namespaces (RestrictNamespaces=), access to block devices (DeviceAllow=char:* rw etc) and lots of system calls could be blocked (SystemCallFilter=@systemd-helper, SystemCallArchitectures=native, MemoryDenyWriteExecute=yes, LockPersonality=yes etc).

Those extreme systems with weird NSS LDAP NFS etc. stuff where anything of the above needs could be expected from puny less tool could opt out.

[Zenmovie]

Cve.mitre assigned vulnerability as CVE-2023-26604. Security mechanisms referred to above appeared in systemd 247. While ubuntu 20 and rhel 8.x use systemd 245.