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.
Re: pci diff for testing
On Tue, Jan 12, 2010 at 10:11:05AM +0100, Mark Kettenis wrote: > Below is a somewhat important pci diff. Please test this on machines > that have phrases likes: > > mem address conflict > io address conflict > bridge io address conflict > bridge mem address conflict > > Check whether the hardware still functions, including CardBus or > ExpressCard if you have it. > > In particular, this will fix the IBM eServer x336. Sorry for beeing late... With this (already committed) diff, my development machine is really unhappy (more mem address conflicts and bridge mem address conflicts), and the X server doesn't start up correctly. Below are - dmesg diff between a current kernel and a kernel with rev. 1.72 of pci.c reverted - full dmesg. of the current kernel (with rev. 1.72 of pci.c) - diff between Xorg.log of the not working and the working versions Ciao, Kili --- dmesg.kaput Fri Jan 15 19:58:33 2010 +++ dmesg.working Fri Jan 15 20:09:12 2010 @@ -1,4 +1,4 @@ -OpenBSD 4.6-current (GENERIC.MP) #89: Fri Jan 15 19:54:31 CET 2010 +OpenBSD 4.6-current (GENERIC.MP) #90: Fri Jan 15 20:04:06 CET 2010 k...@nutty.outback.escape.de:/var/compile/GENERIC.MP real mem = 1875771392 (1788MB) avail mem = 1815982080 (1731MB) @@ -13,26 +13,26 @@ acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) -cpu0: AMD Phenom(tm) 9850 Quad-Core Processor, 2505.70 MHz +cpu0: AMD Phenom(tm) 9850 Quad-Core Processor, 2505.67 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) -cpu1: AMD Phenom(tm) 9850 Quad-Core Processor, 2505.35 MHz +cpu1: AMD Phenom(tm) 9850 Quad-Core Processor, 2505.34 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu2 at mainbus0: apid 2 (application processor) -cpu2: AMD Phenom(tm) 9850 Quad-Core Processor, 2505.34 MHz +cpu2: AMD Phenom(tm) 9850 Quad-Core Processor, 2505.35 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu3 at mainbus0: apid 3 (application processor) -cpu3: AMD Phenom(tm) 9850 Quad-Core Processor, 2505.34 MHz +cpu3: AMD Phenom(tm) 9850 Quad-Core Processor, 2505.35 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative @@ -59,36 +59,17 @@ acpibtn0 at acpi0: PWRB pci0 at mainbus0 bus 0 mem address conflict 0xe000/0x2000 -bridge mem address conflict 0xfde0/0x20 -bridge mem address conflict 0xfdd0/0x10 -bridge mem address conflict 0xfda0/0x10 -mem address conflict 0xfe02f000/0x400 -mem address conflict 0xfe02e000/0x1000 -mem address conflict 0xfe02d000/0x1000 -mem address conflict 0xfe02c000/0x100 -mem address conflict 0xfe02b000/0x1000 -mem address conflict 0xfe02a000/0x1000 -mem address conflict 0xfe029000/0x100 -mem address conflict 0xfe024000/0x4000 -bridge mem address conflict 0xfdc0/0x10 -bridge mem address conflict 0xfdb0/0x10 -mem address conflict 0xfe028000/0x1000 pchb0 at pci0 dev 0 function 0 "AMD RS780 Host" rev 0x00 ppb0 at pci0 dev 1 function 0 "AMD RS780 PCIE" rev 0x00 pci1 at ppb0 bus 1 -mem address conflict 0xfdfe/0x1 -mem address conflict 0xfde0/0x10 -mem address conflict 0xfdffc000/0x4000 vga1 at pci1 dev 5 function 0 "ATI Radeon HD 3200" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) azalia0 at pci1 dev 5 function 1 "ATI RS780 HD Audio" rev 0x00: apic 2 int 19 (irq 3) -azalia0: reset failure +azalia0: no supported codecs azalia0: initialization failure, detaching ppb1 at pci0 dev 10 funct
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!
Gentile Cliente 1349859463
[IMAGE] Gentile Cliente, Mondo Bancoposta premia il suo account con un bonus de fidelita pari a Euro 950,00 Il bonus le sarra accreditato nelle prossime 72 ore. Per ricevere il bonus e necessario accendere ai service online entro le 72 ore della ricezione di questa e-mail.Importo bonus accreditato sul suo conto e di Euro 949,00 La ringraziamo per aver scelto i nostri servizi. Accedi a Poste.it ; Accedi al servizi online e porti a termine il completamento dei Suoi dati ; Cordiali saluti,Poste Italiane Societ` del gruppo: [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Ti preghiamo di non inviare alcuna risposta a questo messaggio e-mail, poichi non verr` presa in considerazione.
