Re: tcpdump privsep design
On Fri, Jan 15, 2010 at 10:21:15PM -0500, Ted Unangst wrote: > On Fri, Jan 15, 2010 at 1:21 PM, Denis Doroshenko > wrote: > > I'd like to give some colleagues possibility to analyze and dump net > > traffic to files, but it seems that in order to do that I need to > > allow them to run a piece of software as root, when the software has a > > possibility to write to a user-defined file and it does it as root. In > > this case I believe they can write files where ever they want, also > > some things won't work (e.g. quotas). > > The current tcpdump code can only be run as root. You can patch the > code to remove the privsep parts if necessary. > > Or, if you generally trust your users except for carelessly filling up > the filesystem, note two things: > 1. When writing to an existing file with -w, tcpdump will not change the > owner. > 2. When running "sudo tcpdump -w - > file", the file will be owned by > the user calling sudo. > > If you don't trust your users to not mess up the file system (what > kind of users are they?), I'd modify the source to only accept a > single -w argument, then force the argument via a shell script they > can run with sudo. But be careful, you'll also have to add NOFOLLOW > to the open call in privsep.c, or they could still overwrite system > files. Alternatively, you could force -w to always write to stdout and use sudo. But remember that you might NOT want to allow -r to read arbitrary files. As you can see, before you know it pretty "interesting" problems pop up. It was a conscious decision to only allow root. The beast is just too complex to trust as a setuid program. -Otto
Re: tcpdump privsep design
On Fri, Jan 15, 2010 at 1:21 PM, Denis Doroshenko wrote: > I'd like to give some colleagues possibility to analyze and dump net > traffic to files, but it seems that in order to do that I need to > allow them to run a piece of software as root, when the software has a > possibility to write to a user-defined file and it does it as root. In > this case I believe they can write files where ever they want, also > some things won't work (e.g. quotas). The current tcpdump code can only be run as root. You can patch the code to remove the privsep parts if necessary. Or, if you generally trust your users except for carelessly filling up the filesystem, note two things: 1. When writing to an existing file with -w, tcpdump will not change the owner. 2. When running "sudo tcpdump -w - > file", the file will be owned by the user calling sudo. If you don't trust your users to not mess up the file system (what kind of users are they?), I'd modify the source to only accept a single -w argument, then force the argument via a shell script they can run with sudo. But be careful, you'll also have to add NOFOLLOW to the open call in privsep.c, or they could still overwrite system files.
Re: tcpdump privsep design
Stuart Henderson wrote: > On 2010/01/15 15:37, Abel Abraham Camarillo Ojeda wrote: > > Why don't you try sudo? you can make rules for each user... > > Reread the first paragraph... > > > Denis Doroshenko wrote: > > > I'd like to give some colleagues possibility to analyze and dump net > > > traffic to files, but it seems that in order to do that I need to > > > allow them to run a piece of software as root, when the software has a > > > possibility to write to a user-defined file and it does it as root. In > > > this case I believe they can write files where ever they want, also > ^ > > > some things won't work (e.g. quotas). > > > Ugh, I forgot tcpdump -w ... -- DISCLAIMER: http://goldmark.org/jeff/stupid-disclaimers/ This message will self-destruct in 3 seconds.
Re: tcpdump privsep design
On 2010/01/15 15:37, Abel Abraham Camarillo Ojeda wrote: > Why don't you try sudo? you can make rules for each user... Reread the first paragraph... > Denis Doroshenko wrote: > > I'd like to give some colleagues possibility to analyze and dump net > > traffic to files, but it seems that in order to do that I need to > > allow them to run a piece of software as root, when the software has a > > possibility to write to a user-defined file and it does it as root. In > > this case I believe they can write files where ever they want, also ^ > > some things won't work (e.g. quotas).
Re: tcpdump privsep design
Denis Doroshenko wrote: > Hi! > > I'd like to give some colleagues possibility to analyze and dump net > traffic to files, but it seems that in order to do that I need to > allow them to run a piece of software as root, when the software has a > possibility to write to a user-defined file and it does it as root. In > this case I believe they can write files where ever they want, also > some things won't work (e.g. quotas). > > The man page at > > http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html > > mentions "You must have read access to /dev/bpf*". While it is true > requirement, seems like it is not sufficient to run tcpdump agains a > network interface. > > It seems in order to do that one needs to run program as root, and > making the binary suid root doesn't help here. > > When tcpdump is suid root, it goes as far as: > > ~ $ tcpdump > tcpdump: ioctl: BIOCSETF: Operation not permitted > ~ $ > > From the source I see that the first thing the privileged parent > process does is the following (file privsep.c, function priv_init): > > sigprocmask(SIG_SETMASK, &oset, NULL); > > /* Child - drop suid privileges */ > gid = getgid(); > uid = getuid(); > > So in case of suid scenario, the process loses suid power and then > later on the following piece: > > case PRIV_SETFILTER: > test_state(cmd, STATE_FILTER); > impl_setfilter(socks[0], cmdbuf, &bpfd); > break; > > calls impl_setfilter, which in turn calls setfilter, which in turn > calls ioctl(bpfd, BIOCSETF, &fcode), which fails with the mentioned > "ioctl: BIOCSETF: %s", strerror(errno) message. > > Was this code designed to be run as root (not just EUID 0)? I ask this > because the code does not work otherwise. Man pages does not clearly > state that and the code only looks for EUID to be 0 while it checks > whether it will go any further and fails later when EUID is set to > UID, and UID is not 0. > > Thanks! Why don't you try sudo? you can make rules for each user... -- DISCLAIMER: http://goldmark.org/jeff/stupid-disclaimers/ This message will self-destruct in 3 seconds.
tcpdump privsep design
Hi! I'd like to give some colleagues possibility to analyze and dump net traffic to files, but it seems that in order to do that I need to allow them to run a piece of software as root, when the software has a possibility to write to a user-defined file and it does it as root. In this case I believe they can write files where ever they want, also some things won't work (e.g. quotas). The man page at http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html mentions "You must have read access to /dev/bpf*". While it is true requirement, seems like it is not sufficient to run tcpdump agains a network interface. It seems in order to do that one needs to run program as root, and making the binary suid root doesn't help here. When tcpdump is suid root, it goes as far as: ~ $ tcpdump tcpdump: ioctl: BIOCSETF: Operation not permitted ~ $ >From the source I see that the first thing the privileged parent process does is the following (file privsep.c, function priv_init): sigprocmask(SIG_SETMASK, &oset, NULL); /* Child - drop suid privileges */ gid = getgid(); uid = getuid(); So in case of suid scenario, the process loses suid power and then later on the following piece: case PRIV_SETFILTER: test_state(cmd, STATE_FILTER); impl_setfilter(socks[0], cmdbuf, &bpfd); break; calls impl_setfilter, which in turn calls setfilter, which in turn calls ioctl(bpfd, BIOCSETF, &fcode), which fails with the mentioned "ioctl: BIOCSETF: %s", strerror(errno) message. Was this code designed to be run as root (not just EUID 0)? I ask this because the code does not work otherwise. Man pages does not clearly state that and the code only looks for EUID to be 0 while it checks whether it will go any further and fails later when EUID is set to UID, and UID is not 0. Thanks!
