[rsbac] Restricting only one program

[Amon Ott]

On Thursday, 4. September 2003 04:19, Samuli Kärkkäinen wrote:
> My goal in using RSBAC is to make those services that are visible to the
> network, apache in particular, more resilient toward the buffer overflow
> type attacks. I want to set up a configuration where apache is allowed to...
> 
> - map_exec libraries
> - read but not write htdocs and certain system file like locales
> - write to logs
> 
> And is not allowed to do nothing else. (I'm skipping some details.) I don't
> want this configuration to have any effect on the rest of the system.

This is a general problem.
 
> I've looked and tried configuring several RSBAC modules, and my impression
> so far that none of them quite provide what I want. The RC module comes
> close, but it has one problem. Let's say files that apache is allowed to
> map_exec has type apache_libs. When I assign a library file to the
> apache_libs type, it's no longer in the General_FD type. Hence, I must
> ensure that the General_User role has proper rights to the apache_libs type.
> This breaks the requirement "configuration shouldn't have any effect on the
> rest of the system". This problem is easy to ignore when there are only a
> few roles and types, but when there are a lot of them, it's hard to feel
> confident General_FD still has the correct rights to all the types.

In any model, you somehow have to tell which files are libraries or htdocs, 
and which ones are not. RC model uses types to do this, but you still have to 
mark the files.

Once you have a small but working base setup, you can copy rights to new 
types from other types, and you can always copy and change existing roles. 
This is my way to make sure that there are appropiate rights for all existing 
roles.
 
> 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.

You would have to create a new group, which contains all users but the apache 
user. New users must be added to this group by your useradd script and 
removed by your userdel script, or manage the groups manually.

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

The only module that allows to restrict a single process tree only is JAIL, 
and it would already help to avoid some vulnarabilities. Use / as chroot dir 
to get most features without setting up a chroot environment. Apache runs 
fine in JAILs, I have done that several times before.
 
Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22