On 01/12/2012 03:18 AM, Bennett Haselton wrote:
> Is this really supposed to get easier over time? :) Now my audit.log
> file shows that SELinux is blocking my cgi script, index.cgi (which is
> what's actually served when the user visits the front page of one of our
> proxy sites like sugarsurfer.com) from having '"read write" to socket
> (httpd_t)'. I have no idea what that means, except that I thought that
> cgi scripts were supposed to be able to write to stdout so that the web
> server could send the data via a socket connection to the end user's
> browser, so I don't know why a CGI script would be blocked from writing
> to a socket with security context httpd_t.
Your cgi script isn't allowed to write to the socket file. The context
httpd_t isn't touchable by your executable. Is your index.cgi script
custom or something from a distro package?
In any case you can find a way to deliberately make this audit message
show up (sounds like you have), try to vary it a few times to get a good
base of audit information, and then use audit2allow to inspect the last
several lines of your audit file.
From this you can have audit2allow create and package a new policy that
explicitely permits just this access and nothing else. See if you get
any more AVC denials (9 out of 10 times this will be the end of it). If
no more AVC notices and everything works well, turn SELinux back to
enforcing and test a bit.
Usually for custom scripts (of any depth, really) this is all that's needed.
I have to do the same thing every time I decide to do something weird
like run a new version of Django on top of Postgres 9.1 from source with
all my other custom database-using apps asking for things from other
servers, etc. Even with that much messaging going around its pretty easy
to pin the situation down.
You will need policycoreutils-python installed and you'll want to read
over the manpages for audit2allow and any other tool that you find
interesting, but its pretty easy now that you've got sane output to go
by, know where/what your audit file is, and what a security context is.
> The only clue that might narrow it down is the line "Target
> Objects socket [ udp_socket ]". The sockets that the cgi
> scripts usually send output to are of course tcp sockets, so why would
> it say udp? The only time one of my cgi scripts might use udp would be
> if it were doing a hostname lookup via dns, but the index.cgi script
> doesn't do that at any point.
No idea why it would need to talk to a UDP socket if you're absolutely
certain that it doesn't need to, but it could be something else related
that needs to do a lookup (Apache set to resolve names for logs, for
example?).
> What would the pros do at this point?
Aside from checking the policy that the audit tools come up with, it
would be reasonable to run a test on the script in a clean environment
(minimal install of the OS with just enough web server (Apache) setup to
let the script execute) and see what is happening in the audit log (and
anywhere else you're curious about -- database, other processes, file
system acces, etc.).
If you're really paranoid (and a pro is paid to be, so...) it would be
good to check the contents of the packets being passed in and out of the
test environment to make sure you fully understand what is expected,
then compare that against what you see coming from the production server.
In *any* case, putting together a quick SELinux policy that let's your
app run and lets you turn SELinux back on is better in the interim than
simply letting the system sit with a permissive policy while you do your
homework.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
