headers
Amon Ott | 1 Sep 2003 10:14

RSBAC vs. LSM / SELinux in 2.6.0-test

On Sunday, 31. August 2003 19:45, Peter Busser wrote:
> At this moment there is a situation where the RSBAC patch and the Linux
> Security Modules patch bite each other. Trying to force both in the 2.4 
kernel
> is like going into a patching hell. It is simply not worth it.
> 
> For 2.6, you have LSM and the SE Linux module (which is only part of SE 
Linux
> I think, the biggest part resides in userland). And I have no idea how the 
2.6
> port of RSBAC is going to work (maybe Amon can comment on that?).

If the LSM and SELinux stubs are in the kernel, they will not clash with 
RSBAC during patch - the RSBAC patch will be against the official tree in any 
case, with or without SELinux.

Based on this current discussion, I will express some of my thoughts about 
LSM / SELinux vs. RSBAC.

As far as I am concerned, some important problems in the LSM design (only 
partly solved by SELinux) are that

- it not by itself allows to register several functions at the same stub, so 
modules have to implement a stacking and Meta decision algorithm by 
themselves. There is a stacker helper module, but this does not seem to be 
included by default.

- it is *very* low level, exporting and exposing kernel internal data 
structures directly to the registered functions and without any abstraction. 
You will have to #ifdef for the kernel version inside these functions,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amon Ott | 2 Sep 2003 09:43

Moved patch-2.4.22-v1.2.2.gz to /patches

...so it is regarded as stable.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
Permalink | Reply | 0 comments |
headers
Samuli Kärkkäinen | 4 Sep 2003 04:19
Picon
Picon

Restricting only one program

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.

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.

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.

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Samuli Kärkkäinen | 4 Sep 2003 04:22
Picon
Picon

A few bugs; RH kernels

1) Some RSBAC configuration utility seems to create file /tmp/temp and leave
it there. I run the guilty utility first as root, so that /tmp/temp gets
created with owner root. Then I run the utility as the security officer, but
now the utility can't overwrite /tmp/temp, and shows some warnings.

2) When ever I try to press the help button in some menu based configuration
utility, the effect is same as pressing the cancel button. Could this be
because of a faulty installation, or is this a known bug?

3) Has it been considered releasing either RSBAC patches against Redhat
kernel sources, or releasing binary rpm's that are based on the Redhat
kernels? I'm going to recommend my company to use RSBAC in its servers, and
I'm sure they'd be much more willing to do that if it didn't require
suspicious manual patching to add RSBAC into a Redhat kernel (which is what
they will keep using).

--

-- 
  Samuli Kärkkäinen                   |\      _,,,---,,_
 skarkkai <at> woods.iki.fi ---------ZZZzz /,`.-'`'    -.  ;-;;,_------
http://www.woods.iki.fi              |,4-  ) )-,_. ,\ (  `'-'
                                     '---''(_/--'  `-'\_)
Permalink | Reply | 1 comment |
headers
Amon Ott | 4 Sep 2003 08:55

Re: A few bugs; RH kernels

On Thursday, 4. September 2003 04:22, Samuli Kärkkäinen wrote:
> 1) Some RSBAC configuration utility seems to create file /tmp/temp and leave
> it there. I run the guilty utility first as root, so that /tmp/temp gets
> created with owner root. Then I run the utility as the security officer, but
> now the utility can't overwrite /tmp/temp, and shows some warnings.

Thanks for telling, there is a left over debug statement in rsbac_fd_menu. 
The attached patch disables it.

> 2) When ever I try to press the help button in some menu based configuration
> utility, the effect is same as pressing the cancel button. Could this be
> because of a faulty installation, or is this a known bug?

This is a known bug in some older dialog versions, where my patch was 
incorrectly adopted. Please try the version at http://rsbac.org/dialog/ with 
the provided patch, it works fine.

> 3) Has it been considered releasing either RSBAC patches against Redhat
> kernel sources, or releasing binary rpm's that are based on the Redhat
> kernels? I'm going to recommend my company to use RSBAC in its servers, and
> I'm sure they'd be much more willing to do that if it didn't require
> suspicious manual patching to add RSBAC into a Redhat kernel (which is what
> they will keep using).

Redhat, like many other distros, heavily patch their kernels with more or 
less stable and useful extra features. RSBAC patches have always been against 
vanilla kernels, I just cannot follow all distributions and create patches 
for their special kernels.

What I do is provide pre-patched vanilla kernels, which you only need to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amon Ott | 4 Sep 2003 09:23

Re: Restricting only one program

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amon Ott | 5 Sep 2003 17:53

RSBAC ported to 2.6.0-test4

Hi!

The port to 2.6.0 is finished at alpha test level. If you are interested, you 
can download the current state from the rsync server at 
http://rsync.rsbac.org/ (or rsbac.dyndns.org for rsync access).

I will soon make a 1.2.3-pre1 for 2.6.0-test4, 2.4.22 and 2.2.25.

BTW: How many people still need 2.2 kernel support? Just to get an idea...

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
Permalink | Reply | 0 comments |
headers
Amon Ott | 10 Sep 2003 17:49

RSBAC v1.2.3-pre1 uploaded

Hi!

Version 1.2.3-pre1 for kernels 2.2.25, 2.4.22 and 2.6.0-test5 has been 
uploaded to http://rsbac.org/pre.

While RSBAC for kernels 2.2.25 and 2.4.22 works as usual, you will have some 
limitation with the 2.6.0 version:

In kernel config,
- go to Menu "Security Options"
- check "Enable different security models" and "Socket and Networking 
Security Hooks"
- disable "Default Linux Capabilities" and "NSA SELinux Support".

Note: You will have no capability functionality with this configuration, so 
RSBAC CAP module will be useless!

The LSM capability module does not include a stacker function to register the 
RSBAC LSM functions as secondary module, so registration to LSM will fail. I 
will have to partially init RSBAC before this module and provide full LSM 
stacking functionality to get a workaround for the IMHO broken LSM stacking 
design. Oh well.

It might work together with SELinux, though, because they added all the 
secondary calls for stacking with a restrictive metapolicy.

If it takes much more work, I will probably throw out the few LSM hooks I 
could use and return to my own hooks. :(

Amon.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuli Kärkkäinen | 12 Sep 2003 05:39
Picon
Picon

ACL menu and RSBAC_EINVALIDTARGET

When using the ACL management menu and choosing a new target, it sometimes
happens that the user interface doesn't list any entries, and in the syslog
appears one or two lines like

rsbac_acl_sys_get_mask(): rsbac_acl_get_mask() returned error RSBAC_EINVALIDTARGET!

This is apparently when the target dependent specifier field (first/second
field from the top) isn't given. Perhaps the contents of that field is kept
the same as with previously used target, which makes the field content
invalid. I haven't managed to figure out exactly when this happens.

This is not actually harmful, but quite confusing. Getting such messages
into the syslog makes one think something is broken. The UI should probably
make it more obvious that the user needs to enter something sensible into
the field in question when its contents aren't valid.

--

-- 
  Samuli Kärkkäinen                   |\      _,,,---,,_
 skarkkai <at> woods.iki.fi ---------ZZZzz /,`.-'`'    -.  ;-;;,_------
http://www.woods.iki.fi              |,4-  ) )-,_. ,\ (  `'-'
                                     '---''(_/--'  `-'\_)
Permalink | Reply | 1 comment |
headers
Samuli Kärkkäinen | 12 Sep 2003 07:07
Picon
Picon

Re: Restricting only one program

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:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane