-
Notifications
You must be signed in to change notification settings - Fork 95
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
Flag readable only by challenge
group
#577
Comments
We should eventually make a page with code snippets in various languages to do permissions related tasks the right way, so that challenge authors don't mess up trying to roll their own. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Can you hear the future of the dojo off in the distance? It says "Challenges shouldn't be setuid-root unless they need to be; they should be setgid-challenge".
The flag shall be readable by only the "challenge" group. And guess what, root has capabilities to ignore these permissions, so it can read too. Most challenges will just be setgid-challenge.
This group shall be ID 1337 or maybe 942 if we should be below 1000 (42 is already the shadow group on ubuntu:24.04).
The simple transition path is to just
chown -R root:challenge /challenge && chmod -R 6755 /challenge
. This means everything will still be setuid-root, but will now also be setgid-challenge. So, challenges that depend on being root (for chroot, binding lower ports, etc) will still work. Long term, most things will just be2755 root:challenge
--which is to say, challenges will not run as root.Experiments
Setup:
We get an "egid" of 1337:
We can read the flag using a setgid program:
We can also still read the flag using a root-setuid program:
We can also read the flag using a setuid-setgid program:
Just like setuid,
/bin/sh
drops setgid (while/bin/sh -p
does not):The text was updated successfully, but these errors were encountered: