[gentoo-hardened] Grsec X11 Rbac Selinux Priviledged/Raw I/O Mprotect Firefox

[gentoo-hardened] Grsec X11 Rbac Selinux Priviledged/Raw I/O Mprotect Firefox

[Kevin Chadwick]

I've been using OpenBSD for a while now which has priv dropping X and
the machdep.allowaperture=[0|1|2]. Theo has said firefox also
annoyingly uses it's own memory management.

I have a few questions about Grsec that I'd love some input on as I am
struggling to find the answers to them at the moment.

I've read on the Gentoo-hardened archive and grsec config help that the
iopl and ioperm should be protected with rbac if priviledged I/O is
allowed.

So you can disable the RAW_IO capability to all and sacrifice xrestarts.
But if X already has all priviledges then I guess your just adding a
hurdle which is made a bit higher with grsec, so obfuscation really
and not complete security. Is there anything else you can do or is that
what is meant by "You should use RBAC if you allow priviledged I/O"?

The gentoo-handbook says something like the question of selinux|rbac|
rsbac is a controversial one. It seems rsbac is the most secure but
more difficult to use and has less starter policies around. Gentoo
seems to have selinux policies. Does selinux have any more to offer than
rbac for protecting X?

Does CONFIG_PAX_MPROTECT_COMPAT have any effect on firefox and did
mozilla refuse to patch their sources with the if !jit patch?

Thanks

Kc

Re: [gentoo-hardened] Grsec X11 Rbac Selinux Priviledged/Raw I/O Mprotect Firefox

[Anthony G. Basile]

On 11/06/2011 06:19 PM, Kevin Chadwick wrote:
> I've been using OpenBSD for a while now which has priv dropping X and
> the machdep.allowaperture=[0|1|2]. Theo has said firefox also
> annoyingly uses it's own memory management.

Hi, I've run many an OpenBSD boxes in my time.

Regarding Xorg.  We do not drop privileges, that might be a good idea.
However, our X runs with almost full privileges.  All toolchain
hardening is on except bind now.  On the kernel side, X will run with
all hardening with the possible exception of CONFIG_GRKERNSEC_IO.  If
you can run RBAC, it will help protect against rogue processes trying to
do iopl/ioperm calls.

As for firefox, I think Theo is referring to its built in malloc (I
forget what its called).  I remember it causing problems, but not the
details.  It may be related to its JIT which needs MPROTECT turned off
to run properly.

> 
> I have a few questions about Grsec that I'd love some input on as I am
> struggling to find the answers to them at the moment.
> 
> I've read on the Gentoo-hardened archive and grsec config help that the
> iopl and ioperm should be protected with rbac if priviledged I/O is
> allowed.
> 
> So you can disable the RAW_IO capability to all and sacrifice xrestarts.
> But if X already has all priviledges then I guess your just adding a
> hurdle which is made a bit higher with grsec, so obfuscation really
> and not complete security. Is there anything else you can do or is that
> what is meant by "You should use RBAC if you allow priviledged I/O"?

I would try running it with CONFIG_GRKERNSEC_IO set and see if it works.
 Try nvidia with nouveau driver, if you have that.  My guess is
proprietary drivers are going to get you in trouble here, so if you have
an ATI, you may have no choice in the matter.

> 
> The gentoo-handbook says something like the question of selinux|rbac|
> rsbac is a controversial one. It seems rsbac is the most secure but
> more difficult to use and has less starter policies around. Gentoo
> seems to have selinux policies. Does selinux have any more to offer than
> rbac for protecting X?

Its recommended that with workstations you run SELinux in targeted mode,
not strict.  So, while it might offer something more for X (and I'm not
sure it does), this means loosening other restrictions that RBAC would
give you on a workstation.

> 
> Does CONFIG_PAX_MPROTECT_COMPAT have any effect on firefox and did
> mozilla refuse to patch their sources with the if !jit patch?
> 
> Thanks
> 
> Kc


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-hardened] Grsec X11 Rbac Selinux Priviledged/Raw I/O Mprotect Firefox

[Javier Juan Martínez Cabezón]

[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]

At least now (AFAIK) with KMS ioperm/iopl is not required, only propietary
drivers need them (and having them running is per se a security bug).

Since now with CONFIG_STRICT_DEVMEM enabled every process is unable to
access to any RAM memory (if not video one and even with CAP_SYS_RAWIO) I
think it's a bit more secure approach.

I think is not obfuscation is a less privilege approach, only those
proccess that need it should get it granted

RBAC can permit you to switch which device can Xorg access even with
CAP_SYS_RAWIO (for example permit it in /dev/mem to access video memory,
but forbid it to /dev/sda as lilo would need for example), dropping
privileges isn't so important because is supposed that (at least with rsbac
and I think that grsec is like this) root is untrusted and by this reason
it's fully controlled.

I think openBSD great lack comes from here, even with dropping, the part
that do ioperm is fully privileged and because of this vulnerable or risky
because in openbsd root can do everything it want (openbsd just only check
for uids, and uid 0 in particular).

GRKERNSEC_IO in resume forbids the use of iopl/ioperm to any userland
application even for those running with CAP_SYS_RAWIO granted, I don't know
if grsec rbac can control it without this switch running (I have not seen
nothing in the grsec documentation wiki).

RSBAC controls it with two requests (GET_STATUS_DATA (read) and
MODIFY_STATUS_DATA (write) against  SCD_IOPORTS, xorg if uses KMS only
requires access to SCD_VIDEOMEM and neither IOPORTS neither SCD_MEM (global
RAM)

Some roles (a user or a binary marked as role) could have both granted,
others roles only one, and other ones not.









2011/11/7 Kevin Chadwick <ma1l1ists@yahoo.co.uk>

> I've been using OpenBSD for a while now which has priv dropping X and
> the machdep.allowaperture=[0|1|2]. Theo has said firefox also
> annoyingly uses it's own memory management.
>
> I have a few questions about Grsec that I'd love some input on as I am
> struggling to find the answers to them at the moment.
>
> I've read on the Gentoo-hardened archive and grsec config help that the
> iopl and ioperm should be protected with rbac if priviledged I/O is
> allowed.
>
> So you can disable the RAW_IO capability to all and sacrifice xrestarts.
> But if X already has all priviledges then I guess your just adding a
> hurdle which is made a bit higher with grsec, so obfuscation really
> and not complete security. Is there anything else you can do or is that
> what is meant by "You should use RBAC if you allow priviledged I/O"?
>
> The gentoo-handbook says something like the question of selinux|rbac|
> rsbac is a controversial one. It seems rsbac is the most secure but
> more difficult to use and has less starter policies around. Gentoo
> seems to have selinux policies. Does selinux have any more to offer than
> rbac for protecting X?
>
> Does CONFIG_PAX_MPROTECT_COMPAT have any effect on firefox and did
> mozilla refuse to patch their sources with the if !jit patch?
>
> Thanks
>
> Kc
>
>

[-- Attachment #2: Type: text/html, Size: 3549 bytes --]

Re: [gentoo-hardened] Grsec X11 Rbac Selinux Priviledged/Raw I/O Mprotect Firefox

[Francisco Blas Izquierdo Riera (klondike)]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

El 07/11/11 18:45, Javier Juan Martínez Cabezón escribió:
> At least now (AFAIK) with KMS ioperm/iopl is not required, only
> propietary drivers need them (and having them running is per se a
> security bug).
I think this doesn't hold for radeon based on my empirical experience
should try again though.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]