On Sun, 2004-08-15 at 16:20, Business DSL User wrote:
> As an experiment, I deleted the dontaudit rules from policy.conf, and built
> and loaded the modified policy. The resulting AVC messages identified about
> a half dozen operations that were failing. One of them seems to be
> responsible for killing Snort. Adding the rule:
>
> allow snort_t sysadm_devpts_t:chr_file { read write };
>
> enables Snort to restart just fine.
>
> Some questions arise:
>
> 1. Is the technique of deleting dontaudit rules valid, or is there a better
> way?
There is an 'enableaudit' target in the policy Makefile that does
precisely that - see the Fedora SELinux FAQ. make enableaudit load,
then make clean load later to revert.
> 2. Is there possibly a better policy tweak that would permit Snort to
> restart okay? I'm not cheerful about giving Snort access to the console.
Update to the latest FC2 kernel and policy. A change was made to
SELinux to re-open descriptors that it closes on exec to the null
device. This avoids inducing program misbehavior when SELinux closes
descriptors.
> 3. What's with Snort trying to access /dev/pts? Seems to me that a
> daemonized program shouldn't do that. So, there's obviously something I
> don't know.
The read/write checks are performed by SELinux on the exec to revalidate
access to the open descriptor, so you would see the audit messages even
if the program never tried to access the descriptor itself (that is why
they are dontaudit'd). With regard to snort dying, a similar issue
existed with apache; it would create a socket (which would get assigned
descriptor 0, since SELinux had closed descriptors 0-2 to the pty), then
close descriptors 0-2 (thinking that they were its stdin/stdout/stderr),
then try to use the socket and fail since it had unwittingly closed it.
With newer kernels, SELinux re-opens such descriptors to the null
device, so that they remain assigned and any read/writes to them are
harmless (e.g. diagnostic output).
--
Stephen Smalley <sds@xxxxxxxxxxxxxx>
National Security Agency
