[Snort-devel] Re: [Snort-users] Chrooting snort
erek at ...105...
Fri Mar 1 00:40:03 EST 2002
[Any developers want to correct my stupidity? Please feel free!]
On Fri, 1 Mar 2002, Alain Tesio wrote:
> I didn't know about this option, but there is no reason why it would behave
> differently in the chroot, the purpose of the chroot command is to provide
> another environment and the process running inside it should behave the same
> way. Indeed the only case I can think is this one, when it tries to chroot
I _really_ hate being made to think hard while trying to watch Star Wars. ;-)
If you use -t <dir> and HUP snort, it _will_ break. The exec family of calls
"replace the current process image with a new process image". Since that's
the case, the chroot call becomes 'recursive' as the snort image gets
Some other thoughts below...
> The error is:
> ERROR: OpenPcap() device eth0 open:
> socket: Operation not permitted
> So it's because it dropped the root privileges and can't open the
> interface again, chrooted or not. Is there a reason why snort close the
> interface when he receives a SIGHUP ?
Well, I'm not a coder so I can't speak for the developers on that. From
looking at the code, it's because of the exec(2) family calls. It reloads and
restarts the whole program, which includes the binding to the interface.
I'm not sure that snort is the one closing the interface. From what I can
track thru the man pages and code, it seems to be due to the way that libpcap
opens the interace. If the interface was opened without the close-on-exec
flag set then it should remain open when snort restarts. But that's handled
by a call out to libpcap, so that's where the change would have to be made (I
> If this constraint is removed, snort could survive the signal if it's
> started with the chroot command and not the -t option.
Right... It would be spiffy, but since 2.0 is coming around the bend, I think
it might have to wait till then (or later) to get 'fixed'.
I think there's a handfull of people who are doing chroot'ing, so it's not too
big of an issue for the developers right now.
> Yes as "ldd snort" says it's using it, it also detects that files like
> /etc/snort.conf, /etc/passwd or the timezone file are needed because
> the process attempts to access them.
Spiffy! That's _MUCH_ more clueful that the Sunworld info I found. I'll have
to take some time this weekend and give that a whirl.
> Well it works for some other things like apache and bind too with similar
> configuration files, and you don't have to feed it manually with a list of
Very, very cool. I know what I'll be tinkering with on Sunday! :)
More information about the Snort-devel