From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RNTGZ-0003f5-Pc for garchives@archives.gentoo.org; Mon, 07 Nov 2011 17:45:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3DBF621C03E; Mon, 7 Nov 2011 17:45:35 +0000 (UTC) Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by pigeon.gentoo.org (Postfix) with ESMTP id E7F2221C026 for ; Mon, 7 Nov 2011 17:45:05 +0000 (UTC) Received: by vws19 with SMTP id 19so4465037vws.40 for ; Mon, 07 Nov 2011 09:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HURaky66bNNOB66AtqQluVse5u2brwbmuVpx/N1klwA=; b=WKuoISbZHx8SdeJm7z+Dmj+WYFc0NMwzD70/BY5ve/dXKjAnNiQM02oVuvLcOc11IB Efw/KEWTZE/GmqPe0OHHQILor3czmKWL/PiIQwTB4RKCFyi27PJQXx7zqtdx/ILKBZal 0KT4SbVD2w8/CfUJ9xYm1fRjSstc5QAmd9p2Q= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.23.12 with SMTP id i12mr8156962vdf.37.1320687903776; Mon, 07 Nov 2011 09:45:03 -0800 (PST) Received: by 10.52.110.41 with HTTP; Mon, 7 Nov 2011 09:45:03 -0800 (PST) In-Reply-To: <20111106231918.33254318.ma1l1ists@yahoo.co.uk> References: <20111106231918.33254318.ma1l1ists@yahoo.co.uk> Date: Mon, 7 Nov 2011 18:45:03 +0100 Message-ID: Subject: Re: [gentoo-hardened] Grsec X11 Rbac Selinux Priviledged/Raw I/O Mprotect Firefox From: =?ISO-8859-1?Q?Javier_Juan_Mart=EDnez_Cabez=F3n?= To: gentoo-hardened@lists.gentoo.org Content-Type: multipart/alternative; boundary=20cf307c9b525d1e4e04b1289d9e X-Archives-Salt: e8370f78-3024-4d8b-a7cf-35916645349d X-Archives-Hash: c91e98f50ec6e483c0931429b5c4525e --20cf307c9b525d1e4e04b1289d9e Content-Type: text/plain; charset=ISO-8859-1 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 > 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 > > --20cf307c9b525d1e4e04b1289d9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 ac= cess to any RAM memory (if not video one and even with CAP_SYS_RAWIO) I thi= nk it's a bit more secure approach.

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

RBAC can permit you to switch which device can Xorg access even with CA= P_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 par= t that do ioperm is fully privileged and because of this vulnerable or risk= y because in openbsd root can do everything it want (openbsd just only chec= k for uids, and uid 0 in particular).

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

RSBAC controls it with two requests (GET_STATUS_DATA (read) and MODIFY_= STATUS_DATA (write) against=A0 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=3D[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<= br> 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&quo= t;?

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


--20cf307c9b525d1e4e04b1289d9e--