As an experiment in playing with the suid bit, I tried writing a script to run apt-get update
from a bash script, and then set the suid bit on it, so I could just run ~/update
or something.
apt-get update
could be anything here - some program that listens on a privileged socket, or writes to /
or anything else that has to be run as root. Please don't latch on to apt-get update
here.
First try is this, which didn't work, failing with can't get lock, are you root?
. The reason would seem to be Setuid bit seems to have no effect on bash.
#!/bin/bash
apt-get update
So I thought I'd try to bypass the shell, but this didn't work either, for the same reason.
#!/usr/bin/perl
system("apt-get", "update").
I've got the permissions correct (afaik) - sudo chmod 4755 ~/update
.
Have I misunderstood setuid, or am I just missing something simple?
sudo strace -fe execve apt-get update
, how many of those applications do you think are safe in a privilege escalation context with untrusted environment? Don't usesetuid
for that, you need to isolate the client. Provide with a service instead (whereapt-get
is run in a trusted context upon the client's request, instead ofapt-get
being called in the client's context). Could be as simple as usinginetd
– Stéphane Chazelas Mar 17 '15 at 15:34sudo
that does a bit of sanitizing on the environment. Best is to use a service approach. setuid should only be considered as the last-resort approach. – Stéphane Chazelas Mar 17 '15 at 17:17suid bit
if you shut down my questions when I attempt to experiment with it? If I say I'm mucking around in a VM, will that satisfy you? – Squidly Mar 17 '15 at 17:20