| 1 |
I've said in the past that I have no problem supporting rsbac but before |
| 2 |
any recruitment or anything like that starts you have to show the |
| 3 |
initiative to get the ebuilds, docs and policy in order. This is a very |
| 4 |
good start but most of the time talk is cheap. |
| 5 |
|
| 6 |
As solar already said, you'd have to take on all bugs relating to rsbac |
| 7 |
ebuilds and policy and get as much documentation as needed online. RSBAC |
| 8 |
has a much higher learning curve than grsec so you'll need much more |
| 9 |
documentation. |
| 10 |
|
| 11 |
I disagree with solar's suggestion that zhware open a bug. Someone on |
| 12 |
the hardened team ought to do this since we'll be recruiting him. Other |
| 13 |
than that everything is in the hands of our newly appointed committee. [1] |
| 14 |
|
| 15 |
1. Oops, I ought to write an email to this list concerning that :) |
| 16 |
|
| 17 |
Joshua Brindle |
| 18 |
|
| 19 |
Ned Ludd wrote: |
| 20 |
|
| 21 |
> On Tue, 2004-04-27 at 16:53, Michal Purzynski wrote: |
| 22 |
> |
| 23 |
>>helo all |
| 24 |
>> |
| 25 |
>>I would like to propose new hardened subproject - RSBAC. |
| 26 |
>> |
| 27 |
>> |
| 28 |
>>SBAC is a flexible, powerful and fast open source access control framework for current Linux kernels, which has been in stable production use since January 2000 (version 1.0.9a). All development is independent of governments and big companies, and no existing access control code has been reused. |
| 29 |
>> |
| 30 |
>>The standard package includes a range of access control models like MAC, RC, ACL (see below). Furthermore, the runtime registration facility (REG) makes it easy to implement your own access control model as a kernel module and get it registered at runtime. |
| 31 |
>> |
| 32 |
>>The RSBAC framework is based on the Generalized Framework for Access Control (GFAC) by Abrams and LaPadula. All security relevant system calls are extended by security enforcement code. This code calls the central decision component, which in turn calls all active decision modules and generates a combined decision. This decision is then enforced by the system call extensions. |
| 33 |
>> |
| 34 |
>>Decisions are based on the type of access (request type), the access target and on the values of attributes attached to the subject calling and to the target to be accessed. Additional independent attributes can be used by individual modules, e.g. the privacy module (PM). All attributes are stored in fully protected directories, one on each mounted device. Thus changes to attributes require special system calls provided. |
| 35 |
>> |
| 36 |
>>From version 1.2.0, all types of network accesses can be controlled individually for all users and programs. This gives you full control over their network behaviour and makes unintended network accesses easier to prevent and detect. |
| 37 |
>> |
| 38 |
>>As all types of access decisions are based on general decision requests, many different security policies can be implemented as a decision module. Apart from the builtin models shown below, the optional Module Registration (REG) allows for registration of additional, individual decision modules at runtime. |
| 39 |
>> |
| 40 |
>>(quotting from www.rsbac.org/overview.htm) |
| 41 |
>> |
| 42 |
>>In hardened project there is already one MAC system - it is selinux. RSBAC can achieve the same level of security, and, (before someone starts flaming, please don't) using some of them is rather about individual preferences not anything else. |
| 43 |
>> |
| 44 |
>>Adding RSBAC would allow for choice for users who want use MAC security system. In fact, we would already have three such a systems: Selinux, RSBAC and Grsecurity ACL. |
| 45 |
>> |
| 46 |
>>What RSBAC require: |
| 47 |
>>Patched Linux kernel (both versions 2.4 and 2.6 are supported) |
| 48 |
>>RSBAC admin tools - small package with utilities for managing RSBAC |
| 49 |
>>(mayby in future) patch for portage, what would allow labeling files from packages after instalation (assignig their type). |
| 50 |
>>Of course policy - minimal working is easy to do, if RSBAC would join to hardened project full policy along with tools would be developed (yes, it needs time). |
| 51 |
>> |
| 52 |
>>Patches for userland are not required. |
| 53 |
>> |
| 54 |
>>Ebuilds and patched kernel can be found on: |
| 55 |
>>zeus.polsl.gliwice.pl/~albeiro/rsbac/1.2.2 (2.4.26 kernel and 1.2.2 n `stable`) |
| 56 |
>>zeus.polsl.gliwice.pl/~albeiro/rsbac/1.2.3 (2.6.5 kernel and 1.2.3 rsbac version 1.2.3 `development`) |
| 57 |
>>along with admin-tools ebuilds in the same dirs. |
| 58 |
>>RSBAC-sources are bascialy hardened-sources without Grsecurity patch but with latest PaX and with RSBAC instead. |
| 59 |
>> |
| 60 |
>>Ebuilds were written by gentoo developer Zhware, from now on i am maintaining these. |
| 61 |
> |
| 62 |
> |
| 63 |
> You should also be willing to take all bugs associated with this in |
| 64 |
> addition to getting some sort of documentation online for hardened |
| 65 |
> gentoo users. If you willing to fully support it then I have no |
| 66 |
> objections. If no objections from any hardened member then I feel zhware |
| 67 |
> should open a bug on your behalf for you to become a developer so you |
| 68 |
> can begin supporting this properly at gentoo. |
| 69 |
> |
| 70 |
> Note to other people wishing to start new sub projects. This is a good |
| 71 |
> example of how said project should be proposed. |
| 72 |
> |
| 73 |
> |
| 74 |
>>Albeiro |
| 75 |
|
| 76 |
|
| 77 |
-- |
| 78 |
gentoo-hardened@g.o mailing list |
Archives