1 |
At least now (AFAIK) with KMS ioperm/iopl is not required, only propietary |
2 |
drivers need them (and having them running is per se a security bug). |
3 |
|
4 |
Since now with CONFIG_STRICT_DEVMEM enabled every process is unable to |
5 |
access to any RAM memory (if not video one and even with CAP_SYS_RAWIO) I |
6 |
think it's a bit more secure approach. |
7 |
|
8 |
I think is not obfuscation is a less privilege approach, only those |
9 |
proccess that need it should get it granted |
10 |
|
11 |
RBAC can permit you to switch which device can Xorg access even with |
12 |
CAP_SYS_RAWIO (for example permit it in /dev/mem to access video memory, |
13 |
but forbid it to /dev/sda as lilo would need for example), dropping |
14 |
privileges isn't so important because is supposed that (at least with rsbac |
15 |
and I think that grsec is like this) root is untrusted and by this reason |
16 |
it's fully controlled. |
17 |
|
18 |
I think openBSD great lack comes from here, even with dropping, the part |
19 |
that do ioperm is fully privileged and because of this vulnerable or risky |
20 |
because in openbsd root can do everything it want (openbsd just only check |
21 |
for uids, and uid 0 in particular). |
22 |
|
23 |
GRKERNSEC_IO in resume forbids the use of iopl/ioperm to any userland |
24 |
application even for those running with CAP_SYS_RAWIO granted, I don't know |
25 |
if grsec rbac can control it without this switch running (I have not seen |
26 |
nothing in the grsec documentation wiki). |
27 |
|
28 |
RSBAC controls it with two requests (GET_STATUS_DATA (read) and |
29 |
MODIFY_STATUS_DATA (write) against SCD_IOPORTS, xorg if uses KMS only |
30 |
requires access to SCD_VIDEOMEM and neither IOPORTS neither SCD_MEM (global |
31 |
RAM) |
32 |
|
33 |
Some roles (a user or a binary marked as role) could have both granted, |
34 |
others roles only one, and other ones not. |
35 |
|
36 |
|
37 |
|
38 |
|
39 |
|
40 |
|
41 |
|
42 |
|
43 |
|
44 |
2011/11/7 Kevin Chadwick <ma1l1ists@××××××××.uk> |
45 |
|
46 |
> I've been using OpenBSD for a while now which has priv dropping X and |
47 |
> the machdep.allowaperture=[0|1|2]. Theo has said firefox also |
48 |
> annoyingly uses it's own memory management. |
49 |
> |
50 |
> I have a few questions about Grsec that I'd love some input on as I am |
51 |
> struggling to find the answers to them at the moment. |
52 |
> |
53 |
> I've read on the Gentoo-hardened archive and grsec config help that the |
54 |
> iopl and ioperm should be protected with rbac if priviledged I/O is |
55 |
> allowed. |
56 |
> |
57 |
> So you can disable the RAW_IO capability to all and sacrifice xrestarts. |
58 |
> But if X already has all priviledges then I guess your just adding a |
59 |
> hurdle which is made a bit higher with grsec, so obfuscation really |
60 |
> and not complete security. Is there anything else you can do or is that |
61 |
> what is meant by "You should use RBAC if you allow priviledged I/O"? |
62 |
> |
63 |
> The gentoo-handbook says something like the question of selinux|rbac| |
64 |
> rsbac is a controversial one. It seems rsbac is the most secure but |
65 |
> more difficult to use and has less starter policies around. Gentoo |
66 |
> seems to have selinux policies. Does selinux have any more to offer than |
67 |
> rbac for protecting X? |
68 |
> |
69 |
> Does CONFIG_PAX_MPROTECT_COMPAT have any effect on firefox and did |
70 |
> mozilla refuse to patch their sources with the if !jit patch? |
71 |
> |
72 |
> Thanks |
73 |
> |
74 |
> Kc |
75 |
> |
76 |
> |