Re: Against LSM

Hi Amon,

I would suggest you to read this article. I think it can be easily
used with RSBAC.

-----> http://james-morris.livejournal.com/11010.html

Shaz.

On 8/28/07, Amon Ott <ao <at> rsbac.org> wrote:
> Hi Shaz!
>
> On Monday 20 August 2007 15:51, shahbaz khan wrote:
> > Thanks for the details. I was studying RSBAC, AppArmor, GrSec and
> > SELinux in the meanwhile when you were on holidays. I am not
> > exagerating but I have fallen in love with RSBAC! Its so neat. The
> > only short comming is that it is not part of the kernel like
> > SELinux and those guys are enjoying with mass debugging and
> > development support. And this is the reason that they have gone
> > ahead with the labeling of networked resources.
>
> Thanks you very much for your encouraging feedback!
>
> > By the way I also found AppArmor people as friendly as you are but
> > SELinux people have an agenda. If you are on their agenda they are
> > helpful but if you propose any ideas they ignore it! I had an
> > argument with Steve about some TE and networking stuff but with all
> > arguments he was not agreeing and Joshua went silent on it.
>
> They probably have their fixed targets from their employers. There is

MAC module

Hello!
I thought MAC module is not supposed to control access to SCD objects. (?)
I can set MAC seclevel for FILE, DIR, USER and PROCESS, but syslog says that
"Sep  3 15:45:03 localhost kernel: 0000000286|rsbac_adf_request(): request MODIFY_SYSTEM_DATA,
pid 2203, ppid 1512, prog_name mysqld, prog_file /usr/sbin/mysqld, uid 26, 
target_type SCD, tid priority, attr none, value none, result NOT_GRANTED (Softmode) by MAC"
Is there any way to get/set MAC seclevel of SCD objects, or maybe I missed something?
Kernel 2.6.22.5/x86_64/pax/rsbac 1.3.5
// wbr
Fix

_______________________________________________
rsbac mailing list
rsbac <at> rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac

Re: MAC module

On Wednesday 05 September 2007 09:19, Fix wrote:
> I thought MAC module is not supposed to control access to SCD
> objects. (?) I can set MAC seclevel for FILE, DIR, USER and
> PROCESS, but syslog says that "Sep  3 15:45:03 localhost kernel:
> 0000000286|rsbac_adf_request(): request MODIFY_SYSTEM_DATA, pid
> 2203, ppid 1512, prog_name mysqld, prog_file /usr/sbin/mysqld, uid
> 26, target_type SCD, tid priority, attr none, value none, result
> NOT_GRANTED (Softmode) by MAC" Is there any way to get/set MAC
> seclevel of SCD objects, or maybe I missed something? Kernel
> 2.6.22.5/x86_64/pax/rsbac 1.3.5

Some checks are hardcoded in the module. I agree that 
MODIFY_SYSTEM_DATA on SCD priority is not critical and should be 
allowed.

The attached patch allows it.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

_______________________________________________
rsbac mailing list
rsbac <at> rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac

Re: Against LSM

On Wednesday 05 September 2007 03:59, shahbaz khan wrote:
> I would suggest you to read this article. I think it can be easily
> used with RSBAC.
>
> -----> http://james-morris.livejournal.com/11010.html

Thanks a lot for this link, very interesting to read.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

SELinux vs. RSBAC

> I was studying RSBAC, AppArmor, GrSec and
> SELinux in the meanwhile when you were on holidays. I am not
> exagerating but I have fallen in love with RSBAC! Its so neat.

Agreed.

"- If SELinux is the highest possible level of system protection, what is RSBAC then?
- A system rushes to the attack!"

> The 
> only short comming is that it is not part of the kernel like
> SELinux

Yes, that is sadly.
I remember Linus' arguments about speed costs, but only one who want it will pay the price, 
is not it?

// wbr
Fix

_______________________________________________
rsbac mailing list
rsbac <at> rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac

Re: SELinux vs. RSBAC

Hi,

Yes your comments are very true. I have been surveying RSBAC, SELinux,
GrSecurity and AppArmor. The best design is RSBAC and GrSecurity is
most suitable for sys admins. SELinux is getting more attention due to
integeration in mainline kernel. AppArmor is not a true MAC solution
but easier, which means more suitable for beginers and home users.

If anybody seriously wants security then RSBAC is the best enhancement
to kernel. I personally think that it lacks a bit in network controls.

Personally I am working on Distributed MAC and I intend to contribute
in future but my study is based upon SELinux due to mass support. My
design is almost independant of the underlying MAC enhancement so
would be portable easily.

If I can get some help on the internals on how the packets are labeled
and understood on both sides of the network w.r.t. code then side by
side I can handle the portability issues. I think considering
poratibilty issues from this point will help so do let me know how
things are.

Shaz

On 9/5/07, Fix <4d876b82 <at> gmail.com> wrote:
> > I was studying RSBAC, AppArmor, GrSec and
> > SELinux in the meanwhile when you were on holidays. I am not
> > exagerating but I have fallen in love with RSBAC! Its so neat.
>
> Agreed.

MAC module

Hello!
I thought MAC module is not supposed to control access to SCD objects. (?)
I can set MAC seclevel for FILE, DIR, USER and PROCESS, but syslog says that
"Sep  3 15:45:03 localhost kernel: 0000000286|rsbac_adf_request(): request MODIFY_SYSTEM_DATA, pid
2203, ppid 1512, prog_name mysqld, prog_file /usr/sbin/mysqld, uid 26, 
target_type SCD, tid priority, attr none, value none, result NOT_GRANTED (Softmode) by MAC"
Is there any way to get/set MAC seclevel of SCD objects, or maybe I missed something?
Kernel 2.6.22.5/x86_64/pax/rsbac 1.3.5

Re: Against LSM

On Wednesday 05 September 2007 03:59, shahbaz khan wrote:
> I would suggest you to read this article. I think it can be easily
> used with RSBAC.
>
> -----> http://james-morris.livejournal.com/11010.html

RSBAC network access control works on connection (TCP/UDP/ etc.) 
level, not on IP level. However, we could probably use netfilter as 
an alternative to label connections - if we find a way to protect the 
netfilter rules and labelling with full access control. Currently, we 
only have SCD firewall for this, which would not be sufficient.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

Re: MAC module

> Some checks are hardcoded in the module. I agree that 
> MODIFY_SYSTEM_DATA on SCD priority is not critical and should be 
> allowed.
> 
> The attached patch allows it.

Thanks.
I think, MODIFY_SYSTEM_DATA on SCD mlock also should be allowed by MAC module, 
especially for GnuPG, to prevent passphrase leaks to swap:

Sep  6 18:01:26 localhost kernel: 0000000881|rsbac_adf_request(): request 
MODIFY_SYSTEM_DATA, pid 5446, ppid 1, prog_name play, prog_file /usr/bin/sox, 
uid 1000, target_type SCD, tid mlock, attr none, value none, result 
NOT_GRANTED (Softmode) by MAC RC ACL
Sep  6 18:10:48 localhost kernel: 0000000891|rsbac_adf_request(): request 
MODIFY_SYSTEM_DATA, pid 1760, ppid 1725, prog_name artsd, 
prog_file /opt/kde/bin/artsd, uid 1000, target_type SCD, tid mlock, attr 
none, value none, result NOT_GRANTED (Softmode) by MAC RC ACL
Sep  6 18:53:55 localhost kernel: 0000000961|rsbac_adf_request(): request 
MODIFY_SYSTEM_DATA, pid 10217, ppid 8425, prog_name gpg, 
prog_file /usr/bin/gpg, uid 1000, target_type SCD, tid mlock, attr none, 
value none, result NOT_GRANTED (Softmode) by MAC RC ACL

// wbr
Fix

_______________________________________________
rsbac mailing list
rsbac <at> rsbac.org

Re: MAC module

On Thursday 06 September 2007 13:03, Fix wrote:
> > Some checks are hardcoded in the module. I agree that
> > MODIFY_SYSTEM_DATA on SCD priority is not critical and should be
> > allowed.
> >
> > The attached patch allows it.
>
> Thanks.
> I think, MODIFY_SYSTEM_DATA on SCD mlock also should be allowed by
> MAC module, especially for GnuPG, to prevent passphrase leaks to
> swap:

Agreed. I have committed the changes to svn, so they will be in the 
next 1.3 release.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22