3 ms·

Why can't we have setuid on shell scripts which are non-writeable? I have often wished for a facility to allow unprivileged users to execute specific predefin

Why can't we have setuid on shell scripts which are non-writeable? I have often wished for a facility to allow unprivileged users to execute specific predefined tasks, and writing C programs for such things would be a huge pain.

ekimekim 10y ago
The issue is that there's an unavoidable race condition which renders SUID for interpreted (ie. #!) executables insecure. Suppose there's some SUID bash script owned by root in the system that starts with "#!/bin/bash". I (an unprivileged user) create a symlink "./foo" to "/path/to/SUID_script". I execute "./foo". The kernel follows foo, reads the SUID script's #!, and so runs "/bin/bash ./foo". Honoring the SUID, bash is run as root. Here's the race. In between the kernel doing this and bash finishing initialisation and reading its script arg, I swap out the "foo" symlink to instead point at "./my_evil_code". So bash reads "./foo" and executes the content as root. I now have arbitrary code execution as root. Are there ways this could be fixed? Possibly. But not easily. It's not enough to just say "SUID can't work through a symlink" - I could've symlinked to the SUID script's parent directory, for example. You can't say "the kernel should pass the fully resolved path to the interpreter", this will break a million scripts that rely on changing behaviour based on $0. I share your pain about wanting an easy, non-compiled means of creating a small SUID program. But I don't see any good way unless something changes. Maybe a util that takes a #! interpreted file, adds an ELF header and some machine code that execs the desired interpreter and feeds it static script content?
- zem 10y ago
  > I share your pain about wanting an easy, non-compiled means of creating a small SUID program. But I don't see any good way unless something changes. i think the way to go is to just to have a compiled language that makes it easy to write bash-like programs. julia has a pretty nice-looking subprocess module, for instance: http://docs.julialang.org/en/release-0.4/manual/running-external-programs/ http://docs.julialang.org/en/release-0.4/manual/running-exte...
Tiksi 10y ago
Isn't this exactly what sudo / sudoers is for? You can specify a single command or even restrict down to which arguments an unprivileged user can pass to that one command.
- superuser2 10y ago
  I suppose so, but I'd much rather work with a directory of files than a dense config file inside visudo.
  - Tiksi 10y ago
    You could do something like unprivuser ALL=NOPASSWD:/usr/bin/bash /path/to/directory/with/files/* It'd be a mild annoyance to have to explicitly run them with bash: sudo bash /path/to/directory/with/files/thingtorun but you wouldn't have to mess with the config past that.
    - Godel_unicode 10y ago
      Pro-tip: if you're going to go this route, stick these lines in a file in sudoers.d as you're likely to end up with a lot of them, this will help make your config more readable.

ekimekim 10y ago

The issue is that there's an unavoidable race condition which renders SUID for interpreted (ie. #!) executables insecure. Suppose there's some SUID bash script owned by root in the system that starts with "#!/bin/bash". I (an unprivileged user) create a symlink "./foo" to "/path/to/SUID_script". I execute "./foo". The kernel follows foo, reads the SUID script's #!, and so runs "/bin/bash ./foo". Honoring the SUID, bash is run as root. Here's the race. In between the kernel doing this and bash finishing initialisation and reading its script arg, I swap out the "foo" symlink to instead point at "./my_evil_code". So bash reads "./foo" and executes the content as root. I now have arbitrary code execution as root. Are there ways this could be fixed? Possibly. But not easily. It's not enough to just say "SUID can't work through a symlink" - I could've symlinked to the SUID script's parent directory, for example. You can't say "the kernel should pass the fully resolved path to the interpreter", this will break a million scripts that rely on changing behaviour based on $0. I share your pain about wanting an easy, non-compiled means of creating a small SUID program. But I don't see any good way unless something changes. Maybe a util that takes a #! interpreted file, adds an ELF header and some machine code that execs the desired interpreter and feeds it static script content?

zem 10y ago
> I share your pain about wanting an easy, non-compiled means of creating a small SUID program. But I don't see any good way unless something changes. i think the way to go is to just to have a compiled language that makes it easy to write bash-like programs. julia has a pretty nice-looking subprocess module, for instance: http://docs.julialang.org/en/release-0.4/manual/running-external-programs/ http://docs.julialang.org/en/release-0.4/manual/running-exte...

Tiksi 10y ago

Isn't this exactly what sudo / sudoers is for? You can specify a single command or even restrict down to which arguments an unprivileged user can pass to that one command.

superuser2 10y ago
I suppose so, but I'd much rather work with a directory of files than a dense config file inside visudo.
- Tiksi 10y ago
  You could do something like unprivuser ALL=NOPASSWD:/usr/bin/bash /path/to/directory/with/files/* It'd be a mild annoyance to have to explicitly run them with bash: sudo bash /path/to/directory/with/files/thingtorun but you wouldn't have to mess with the config past that.
  - Godel_unicode 10y ago
    Pro-tip: if you're going to go this route, stick these lines in a file in sudoers.d as you're likely to end up with a lot of them, this will help make your config more readable.