| 1 |
On Mon, 12 Dec 2011 22:04:30 +0100 |
| 2 |
Javier Juan Martínez Cabezón wrote: |
| 3 |
|
| 4 |
> |
| 5 |
> Noexec is not usefull at all I give you the reason it does not |
| 6 |
> controls scripts interpretation is a false sense of security. Is |
| 7 |
> something like get a not executable stack without pax mprotect, it |
| 8 |
> does nothing alone |
| 9 |
> |
| 10 |
|
| 11 |
It is an extra security measure for defense in depth. |
| 12 |
|
| 13 |
It allows easy use and a better default widely understood and |
| 14 |
blanket setting that almost any user can understand and switch off and |
| 15 |
so is more likely (not very) to be applied across the board. |
| 16 |
|
| 17 |
It gives admins extra control. |
| 18 |
|
| 19 |
Shall we get rid of file permissions because we have RBAC. We could |
| 20 |
but I can't see that happening and for good reason. |
| 21 |
|
| 22 |
Who said it was lonely :) |
| 23 |
|
| 24 |
> My system has no root, root has all capabilities in 0, so the same |
| 25 |
> privileges as a normal user has, can't do ptrace to others process, |
| 26 |
> can't read files not our, can't load modules etc etc etc. Every |
| 27 |
> capability is removed. Check rsbac.org. With rbac even root can't |
| 28 |
> access a program he has started. Read about rbac and when you get |
| 29 |
> understood which it offers then told me what it can or what does not |
| 30 |
> offers. |
| 31 |
> |
| 32 |
|
| 33 |
I do and I disagree here though we are both right really as has been |
| 34 |
the case for most of this discussion. RBAC can restrict root and |
| 35 |
root has the potential to make Direct attacks on the kernel via the |
| 36 |
memory, accessible devices and perhaps even RBAC itself. Things do |
| 37 |
require priviledges and RBAC reduces those granted and is good but if |
| 38 |
RBAC removed root the kernel wouldn't be able to turn on and off RBAC |
| 39 |
and the boot phase wouldn't be vulnerable. I already realised that RBACs |
| 40 |
were path and Role based, some inode based and probably many other |
| 41 |
flavours. I looked over that pdf but I do have far better ones that |
| 42 |
don't belittle systrace like you do. |
| 43 |
|
| 44 |
> Systrace is dead, the project is dead. It does not exists from long ago. |
| 45 |
|
| 46 |
> > |
| 47 |
> > No it doesn't it restricts root. An exploit may bypass RBAC it may |
| 48 |
> > bypass mount restrictions it may bypass both it may only bypass one, in |
| 49 |
> > which case they are both again useful. |
| 50 |
> > |
| 51 |
> > And OpenBSDs systrace can restrict a lot. System calls are the |
| 52 |
> > hearts heart of an OS. |
| 53 |
> |
| 54 |
> I have said to you that rbac can make impossible to launch untrusted |
| 55 |
> code (even exploits) executed and interpreted as in perl myperlscript. |
| 56 |
> In one of my first mail I pointed you ways in that root can do harm |
| 57 |
> and how rbac can avoid them. Root is not important because root is |
| 58 |
> only important in DAC not in RBAC. Read the link I sen't to you before |
| 59 |
> because you stills not understood this point. |
| 60 |
> |
| 61 |
|
| 62 |
I knew this |
| 63 |
|
| 64 |
> Yes an system dead long ago, and not it only do this: after this bind |
| 65 |
> you can only get a listen. It gives not flexibility, granularity at |
| 66 |
> all. |
| 67 |
|
| 68 |
|
| 69 |
Admittedly systrace doesn't get much attention but then it does what it |
| 70 |
says on the tin and how about Aug 2011. |
| 71 |
|
| 72 |
http://marc.info/?l=openbsd-tech&m=131484069706394&w=2 |
| 73 |
|
| 74 |
This pdf is a bit old (2005) but it actually says the problem with |
| 75 |
systrace is that it is so fine grained it is hard to setup well. |
| 76 |
|
| 77 |
"http://z.cliffe.schreuders.org/publications/Honours%20Thesis.pdf" |
| 78 |
|
| 79 |
|
| 80 |
Lets make this constructive. Maybe you can tell me which RBAC you use |
| 81 |
and why you chose it. |
| 82 |
|
| 83 |
Thanks |
| 84 |
|
| 85 |
Kc |
Archives