[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About audit2allow generated rules

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


   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?


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
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

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!

Reply to: