On Mon, 12 Dec 2011 22:04:30 +0100
Javier Juan Martínez Cabezón wrote:

> 
> Noexec is not usefull at all I give you the reason it does not
> controls scripts interpretation is a false sense of security. Is
> something like get a not executable stack without pax mprotect, it
> does nothing alone
> 

It is an extra security measure for defense in depth.

It allows easy use and a better default widely understood and
blanket setting that almost any user can understand and switch off and
so is more likely (not very) to be applied across the board.

It gives admins extra control.

Shall we get rid of file permissions because we have RBAC. We could
but I can't see that happening and for good reason.

Who said it was lonely :)

> My system has no root, root has all capabilities in 0, so the same
> privileges as a normal user has, can't do ptrace to others process,
> can't read files not our, can't load modules etc etc etc. Every
> capability is removed. Check rsbac.org. With rbac even root can't
> access a program he has started. Read about rbac and when you get
> understood which it offers then told me what it can or what does not
> offers.
> 

I do and I disagree here though we are both right really as has been
the case for most of this discussion. RBAC can restrict root and
root has the potential to make Direct attacks on the kernel via the
memory, accessible devices and perhaps even RBAC itself. Things do
require priviledges and RBAC reduces those granted and is good but if
RBAC removed root the kernel wouldn't be able to turn on and off RBAC
and the boot phase wouldn't be vulnerable. I already realised that RBACs
were path and Role based, some inode based and probably many other
flavours. I looked over that pdf but I do have far better ones that
don't belittle systrace like you do.

> Systrace is dead, the project is dead. It does not exists from long ago.

> >
> > No it doesn't it restricts root. An exploit may bypass RBAC it may
> > bypass mount restrictions it may bypass both it may only bypass one, in
> > which case they are both again useful.
> >
> > And OpenBSDs systrace can restrict a lot. System calls are the
> > hearts heart of an OS.
> 
> I have said to you that rbac can make impossible to launch untrusted
> code (even exploits) executed and interpreted as in perl myperlscript.
> In one of my first mail I pointed you ways in that root can do harm
> and how rbac can avoid them. Root is not important because root is
> only important in DAC not in RBAC. Read the link I sen't to you before
> because you stills not understood this point.
> 

I knew this

> Yes an system dead long ago, and not it only do this: after this bind
> you can only get a listen. It gives not flexibility, granularity at
> all.


Admittedly systrace doesn't get much attention but then it does what it
says on the tin and how about Aug 2011.

http://marc.info/?l=openbsd-tech&m=131484069706394&w=2

This pdf is a bit old (2005) but it actually says the problem with
systrace is that it is so fine grained it is hard to setup well.

"http://z.cliffe.schreuders.org/publications/Honours%20Thesis.pdf"


Lets make this constructive. Maybe you can tell me which RBAC you use
and why you chose it.

Thanks

Kc