[rsbac] Restricting only one program

[Samuli Kärkkäinen]

On Thu, Sep 04, 2003 at 09:23:19AM +0200, Amon Ott wrote:
> On Thursday, 4. September 2003 04:19, Samuli Kärkkäinen wrote:
> > The ACL module seems to have a little difficult approach as well. If I have
> > understood correctly, all users always belong to the GROUP_0. Hence they
> > have all rights, unless I remove rights from GROUP_0. If I remove rights
> > from GROUP_0, all users in the system are affected. This makes it hard to
> > limit the scope of configuration to affect only one service.
> 
> Your case is a good example for a useful combination of RC and ACL:
> 
> - Create an Apache RC role as a copy of General_Role (rc_copy_role or 
> rsbac_rc_role_menu)
> - Add the same ACL rights for the three predefined RC roles 0-2 that Group 0 
> has (you can use the acl_tlist commands from the backup_all script to find 
> them, leave out / for FD targets to speed it up)
> - Set the necessary right for Apache role explicitely
> - Set the role as apache program and/or user role
> - Remove Group 0's rights

Thank you for this suggestion, it's a good one. I went and did this, and I'm
having a small problem. When I start or stop apache, I get about 20 syslog
messages like this:

rsbac_adf_request(): request CLOSE, pid 7438, ppid 7437, prog_name httpd,
uid 0, target_type FIFO, tid Device 00:05 Inode 88593 Path pipe:/[88593],
attr , value 0, result NOT_GRANTED by ACL

The only differing thing in the messages is the pipe inode. If I turn off
softmode and start apache, then after first error like above, I get also a
syslog message:

filp_close() [sys_close]: ADF-call returned NOT_GRANTED

If I give FD :DEFAULT: right CLOSE, these errors go away. However if I give
the same right to FD /, the errors stay. Does this mean :DEFAULT: includes
the FIFO target type, while FD / includes only DIR and FILE types? What
would be the right way to get rid of these errors?

I also have PaX in this kernel, FWIW.

> > The AUTH module by default allows nothing. I haven't found a way to make it
> > default to allowing everything, while allowing limiting rights of only
> > selected programs. Again, this makes it hard to create configuration whose
> > scope is limited to only apache and a few other programs.
> 
> AUTH model must be restrictive, otherwise it would not be secure. If you 
> want, I can add a compile time option to default auth_may_setuid to 1, but 
> this option would be marked as discouraged. I already thought about making 
> AUTH capabilities inheritable from parent dir, but this seemed too dangerous 
> to me. It would have allowed to set defaults at / and set other values 
> explicitely at a lower dir level.

I think it would be a good idea to make AUTH capabilities inheritable. That
would

- fit well within the way other modules work
- provide good flexibility (fe. "allow SUIDs under /usr only")
- be easier to use than compile time option

While security must obviously be the highest priority in things like this,
the ease of use is also very important. Security tools such as RSBAC aren't
used very widely because they are lacking in power, but because they are
quite difficult to use. Therefore, I believe that making RSBAC easier to use
does more to increase the effective security of real world systems than does
increasing its already high degree of achieveable security.

Also if a distribution makes RSBAC part of its kernels, any user who wants
to stick to distribution kernels won't have the option of changing any
compile time options.

-- 
  Samuli Kärkkäinen                   |\      _,,,---,,_
 skarkkai at woods.iki.fi ---------ZZZzz /,`.-'`'    -.  ;-;;,_------
http://www.woods.iki.fi              |,4-  ) )-,_. ,\ (  `'-'
                                     '---''(_/--'  `-'\_)