chroot() RANDOM failure? (:very confused:)

[Striek]

Ok before I gop to bed I better post this since my sleeping pills **** with my memory.

I'm running a home gateway server here with a BASIC iptables firewall. It provides dhcp and dns via proxy to local clients. Plans are in the works for implementing a squid proxy and webmin. This is a Slackware 10.1 box running on a p4 2.4 with 512mb RAM and a 2.4.29 kernel (will update to 2.6 when time allows).

Other than network services, it is running an apache webserver, a mysql server, and snort, all on normal ports. Snort logs its alerts to a mysql database, which is then queried by BASE. I would imagine that other stugg like cusom logging is irrelevant to the problem.

Snort, mysql, and Apache(httpd) are all chrooted off to /home/snort, home/mysql, and home/snort, respectively. (I like to think of these services as users and give them accounts, quotas, and more or less treat and imagine them just as normal users on my system. "Virtual people", basically. It helps me visualize it.)

All three were up and running just fine and using the most recent versions avaible as of last week.

So I was updating the snort rules with rules from BleedingSnort, when I ran into some problems. The rules were updated fine, and besides wasting two hours editng snort.conf instead of snort.conf.eth1/snort.conf.ppp0, everything worked. I hadn't got any new alerts with the new rules yet though, so I tried restarding snort just to be sure. (This worked 5 minutes ago)

~/scripts/snortstart (my script which starts the right snort processes on the right interfaces with the right config files): Basically,
chroot /home/snort /bin/snort_inline -c /etc/snort.conf.ppp0 -l /var/log -i ppp0

I get the following error:

chroot: /bin/snort_inline: permission denied

Starting snort without the chroot wrapper binary works fine, however.

Check the permissions - everything is fine. But, just in case, "chmod -R 777 /home/snort/*"

I try my snortstart script again

chroot: /bin/snort_inline: permission denied

So all the permissions are good and the file is there and executab;e, but it won't run. Hrm.

Ok, try setting chroot suid

Nope. Same error message.

So I run strace against snort_inline and all I get is basically the same error:

strace chroot /home/snort /bin/snort_inline

After "chroot /home/snort" and chdir "/", i get:

execve("/usr/sbin/chroot", ["chroot", "/home/snort", "/bin/snort_inline"], [/* 30 vars */]) = -1 (ENOACCESS)
With no system calls earlier to explain the problem. Just a few library searches, which eventually found what they were looking for. Again, directory and file permissions are as they should be.

Crap. Well maybe snort_inline isn't returing enough information to see the strace result well enough. So I put strace into /home/snort/bin and run it from there against snort_inline like this (all the needed libraries are already in that chroot jail):

chroot /home/snort /bin/strace /bin/snort_inline

and

chroot: strace: permssion denied

Again, the permissions are checked and everything is in order. I set chroot to suid just to be sure with the same results. chroot can properly chroot to / and run stuff from there, so it's not a bad shell.

So maybe a trojan comes to mind. I check the md5 sums against some core utilities on another box (aide is not installed yet). ls, ps, su, chroot, and a bunch of other stuff checks out fine.

So there is no reason I can see that would possibly explain my problem. chroot just doesn't like me.

I give up. Time for a smoke.

...

I come back. Lets test it again.

POOF! Everything works as it should, despite the fact that I have not changed anything in the mean time. I can now run anything chrooted that I wish. I did nothing (I know of) to cause the problem, and certainly did nothing to solve it. It just kind of disappeared. Since it's not a problem anymore, it's not a priority either, but I would be really interested to find out what caused it.

So if this is making sense to people great. If you can enlighten me, even better. But since I'm writing this in a scramble before my memory gets totally screwed I may have forgot things that happened or remembered things that didn't. But you generally get the gist of what happened. chroot *just stopped working*. Most of the technical details should be correct.

This has me completely and totally flabbergasted. Anyone seen this before? Any ideas?

[zENGER]

Only two variables I can think of might be, the user you executed the command with, and the location from which you executed it.

[steve.milner]

The answer to every computer anomoly is now clear:

http://www.newscientist.com/article....mg18725074.600