Re: About audit2allow generated rules

[Min Wang <ser.basis@gmail.com>]

HI Russell
   thanks a lot. that is really helpful.

   just wondering where is the tclass=sock_file defined?

  basically i have apache mod_tile want to access

/var/run/renderd/renderd.sock ( from renderd)

ls -lZ /var/run/renderd/
-rw-r--r--. apache apache system_u:object_r:initrc_var_run_t:s0 renderd.pid
srwxrwxrwx. apache apache system_u:object_r:var_run_t:s0   renderd.sock
-rw-r--r--. apache apache system_u:object_r:initrc_var_run_t:s0 
renderd.stats

    how can I change /define

tclass=sock_file

   to something like tclass=renderd_sock_file?

or change /var/run/renderd/renderd.sock to some something like: 
var_run_renderd_t?

   what I want to do is  just granting the permission that is needed?
   or generally is there a simple way to how to define/write a policy
that only give the needed permission ( there are some howto seems still 
complicated??) ?
not just rely on  aduit2allow to do the magic blindly?



min

On 04/26/2012 12:00 AM, Russell Coker wrote:
> On Thu, 26 Apr 2012, Min Wang<ser.basis@gmail.com>  wrote:
> >        I have something in /var/log/audit/audit.log like:
> >
> > avc:  denied  { write } for  pid=23739 comm="httpd" name="renderd.sock"
> >     dev=dm-0 ino=1183752 scontext=unconfined_u:system_r:httpd_t:s0
> >     tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
> >
> >
> > use audit2allow it generates something like this:
> >
> > allow httpd_t var_run_t:sock_file write;
> >
> >
> > Is the rule too liberal? that means httpd_t can write any var_run_t 's
> > sock_file?
> > Or I miss-understand something?
> Ideally there should be no sock_file objects with type var_run_t, every Unix
> domain socket should have a type which is derived from the domain of the
> process which creates it.  So having one such socket is an indication of your
> configuration not being ideal.  If you only have one daemon with policy that
> allows such sockets then it's probably not a big deal to grant access to
> httpd_t.
>
> Think of var_run_t being similar to the nobody UID in this case.  Having
> exactly one daemon running as nobody theoretically isn't a security problem,
> but having two daemons running with that UID probably is.  The problem is that
> people tend not to stop at one, if they have one daemon running in that manner
> then they may end up with two (through a repeat of the same choices) - so it's
> best to stick with zero!