Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$XDG_RUNTIME_DIR is already "nodev,nosuid", shouldn't it also be "noexec"? #4081

Closed
1 task done
kkovacs opened this issue Sep 1, 2016 · 3 comments
Closed
1 task done
Labels
login needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer RFE 🎁 Request for Enhancement, i.e. a feature request

Comments

@kkovacs
Copy link

kkovacs commented Sep 1, 2016

Submission type

  • Request for enhancement (RFE)

systemd version the issue has been seen with

231

Used distribution

Arch Linux

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

$XDG_RUNTIME_DIR is already "nodev,nosuid", shouldn't it also be "noexec"?

@poettering
Copy link
Member

Why shouldn't apps be allowed to place executable runtime-generated scripts there? There's nothing really risky about that?

@poettering poettering added RFE 🎁 Request for Enhancement, i.e. a feature request login needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer labels Oct 7, 2016
@kkovacs
Copy link
Author

kkovacs commented Oct 7, 2016

Asking the question in reverse: must systemd always provide a filesystem where arbitrary binaries can be made executable?

If someone is trying to build a system (say, an embedded one) where – as part of a "defense in depth" strategy – he tries to prevent users from making arbitrary binaries executable, right now that's impossible because systemd automatically provides a file system for that.

I believe there would be value in making this to be configurable instead of being hardwired.

P.s.: Keep up the good work!

@poettering
Copy link
Member

well, I am not a believer in "noexec" I must say, as you can easily circumvent its effect for both ELF and scripts.

More importantly though, I think the way the XDG basedir spec is currently written suggests that +x should be possible and supported. It doesn't say this directly, but it does say "The directory MUST by fully-featured by the standards of the operating system. More specifically, on Unix-like operating systems …, proper permissions, … must be supported, …". See:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

The difference between noexec on one hand and nodev and nosuid on the other is that noexec actually limits what unprivileged users can do wth the directory, while nodev/nosuid restricts stuff unprivileged users should not have access to in the first place. As XDG_RUNTIME_DIR is per-user anyway, I think it#s a good idea to use nodev/nosuid, but I'd claim that setting noexec would be a bad idea, and contrary to what the spec suggests (at least how I'd read the spec). (Disclaimer: in a previous life I actually wrote that part of the spec, hence I think my interpretation of the spec is the right one ;-)).

One of the issues I see with "noexec" is the effect it has on MAP_EXEC memory maps. As soon as you turn it on, mmap() with MAP_EXEC on all files on it will fail, and I am not sure we should disallow that, as JIT compilers and whatnot might actually rightfully want to use this on runtime files they created there.

And of course, there's always the compat issue as well, changing behaviour might break stuff, hence we should only do it if we have really good reasons. And history tells us that "noexec" has a very good chance to break stuff. For example, when it was first attempted to make /dev noexec the MAP_EXEC issue broke X11, because it wanted to map device nodes/BIOS memory blobs from /dev like that...

All of the above makes me quite uncomfortable changing this now. I don't see the strong benefit of doing this, I only see issues with it.

Hence I am going to close this now. I hope this makes some sense!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
login needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer RFE 🎁 Request for Enhancement, i.e. a feature request
Development

No branches or pull requests

2 participants