1 |
> It is an extra security measure for defense in depth. |
2 |
> |
3 |
> It allows easy use and a better default widely understood and |
4 |
> blanket setting that almost any user can understand and switch off and |
5 |
> so is more likely (not very) to be applied across the board. |
6 |
> |
7 |
> It gives admins extra control. |
8 |
> |
9 |
|
10 |
A inefficient and useless layer if not complemented with extra measures. |
11 |
|
12 |
> Shall we get rid of file permissions because we have RBAC. We could |
13 |
> but I can't see that happening and for good reason. |
14 |
|
15 |
file permissions are discrectional, rbac mostly mandatory, don't try |
16 |
to compare them. |
17 |
|
18 |
|
19 |
> I do and I disagree here though we are both right really as has been |
20 |
> the case for most of this discussion. RBAC can restrict root and |
21 |
> root has the potential to make Direct attacks on the kernel via the |
22 |
> memory, accessible devices and perhaps even RBAC itself. Things do |
23 |
> require priviledges and RBAC reduces those granted and is good but if |
24 |
> RBAC removed root the kernel wouldn't be able to turn on and off RBAC |
25 |
> and the boot phase wouldn't be vulnerable. I already realised that RBACs |
26 |
> were path and Role based, some inode based and probably many other |
27 |
> flavours. I looked over that pdf but I do have far better ones that |
28 |
> don't belittle systrace like you do. |
29 |
|
30 |
It does not restrict root, it erase it. The concept of root doesn't |
31 |
exists anymore. |
32 |
Give me an example of direct attack via memory as you say, accessible |
33 |
devices and anything else said you before. |
34 |
|
35 |
Raw access is fully controlled and forbidden to root, raw access to |
36 |
ttys and block devices too, controlled the mount of devices etc etc |
37 |
etc |
38 |
|
39 |
You don't know what rbac is so don't speak about it because you can't |
40 |
understand it |
41 |
|
42 |
|
43 |
> |
44 |
> Lets make this constructive. Maybe you can tell me which RBAC you use |
45 |
> and why you chose it. |
46 |
> |
47 |
> Thanks |
48 |
> |
49 |
> Kc |
50 |
> |
51 |
I use rsbac as framework, with modules RC, ACL, exclusive UM, RES, |
52 |
JAIL, MAC, PAX, AUTH and CAP running. |
53 |
|
54 |
Root has not capabilities, not CAP_SYS_RAWIO, no DAC_OVERRIDE, not |
55 |
SYS_MODULES etc etc he can only execute binaries in /sbin and /bin, |
56 |
map /lib libraries and nothing else, halt has its own role and type, |
57 |
so root even can't switch down the machine for example. Master role of |
58 |
sshd even has more privileges than root itself. |
59 |
|
60 |
I use rsbac because it reachs to B1 security level, level that openbsd |
61 |
will never reach, it supports even secure_delete, and has some B2 |
62 |
charateristics as device labels are. |