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 1PcIKt-0004jJ-4o for garchives@archives.gentoo.org; Mon, 10 Jan 2011 14:03:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0E7C1E0592 for ; Mon, 10 Jan 2011 14:03:01 +0000 (UTC) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by pigeon.gentoo.org (Postfix) with ESMTP id 51D09E0565 for ; Mon, 10 Jan 2011 13:44:20 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta15.emeryville.ca.mail.comcast.net with comcast id tP4e1f0011HpZEsAFpkKZ6; Mon, 10 Jan 2011 13:44:19 +0000 Received: from [10.1.13.52] ([96.244.142.3]) by omta14.emeryville.ca.mail.comcast.net with comcast id tpk51f00J04cPRL8apk7Ch; Mon, 10 Jan 2011 13:44:17 +0000 Message-ID: <4D2B0D26.3000601@gentoo.org> Date: Mon, 10 Jan 2011 08:44:06 -0500 From: Chris PeBenito Organization: Gentoo Linux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 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 To: Sven Vermeulen CC: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] SELinux documentation draft References: <20110106223208.GA29456@siphos.be> In-Reply-To: <20110106223208.GA29456@siphos.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 193cbbf8-3785-411f-8cad-7a1ead4cc70c X-Archives-Hash: e5a6e35d24eb0c961a90d6dade88f97b On 1/6/2011 5:32 PM, Sven Vermeulen wrote: > I've been working on bringing the SELinux handbook as currently available on > http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml more > up2date. It's somewhat of a rewrite, but with all elements of the original > SELinux handbook still inside it (apart from the troubleshooting as I guess > those are quite outdated, being from 2006 and older). The troubleshooting is not outdated, though there could be a few additions. > The draft is currently available in the hardened-docs.git repository. In > http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=tree;f=html/selinux;hb=HEAD > you should be able to select individual chapters (HTML format) in the "raw" > tree to view them somewhat like they would on the Gentoo site, but for your > convenience there's also a PDF available at > http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=tree;f=pdf;hb=HEAD I looked through section 1 and 2 of the pdf version, and here are my notes so far: 1.2.1 The best way to look at security is by defining your security goals. An example would be protecting critical system files, such as the kernel image, shadow passwords, and SELinux policy binary from being written except by trusted processes. 1.2.2 I don't understand the point of this section 1.2.3 I'd say this is not appropriate for this document. 1.2.4 This has problems; authentication is related to access control, but not part of it. Also, "discretionary" in the sense of access control means that users can change the policy. Contrast that with mandatory access control, where the security admin sets the policy. 1.3.1 SELinux has been included in the kernel for years, we can drop the "kernel patch" part. 2.2.1 This should be users, roles, and types. "Domain" used in SELinux refers to a type that labels a process. The amount of access to unlabeled processes is defined by the policy, not by the SELinux mechanisms. I also think that the newrole example is out of scope for this section. 2.2.2 "Contexts for permission rules" doesn't make sense. "Rules" or "Access control policy" or something similar makes more sense. You also jump into rules with no discussion of object classes. The part where you say that if access is denied by DAC, then SELinux isn't checked should be earlier in the intro. 2.3.1 same thing about domain vs. type. A type is not a state, it is a security attribute. 2.3.2 I think discussion of the specific rules required for a successful domain transition are not relevant for this part of the doc. 2.4.1 You say what can be technically done by using a role, but you don't discuss what the concept of a role is. 2.4.2 Technically, the only default role is object_r. The remainder are just common ones that you see if you use refpolicy. 2.4.3 The key reason for having a SELinux user id that is separate from the Linux user id is that the seuser doesn't change during a login session, but the Linux uid can be changed, eg by setuid or su. 2.5.1 The purpose of MLS is to provide a hierarchical confidentiality policy. "This allows administrators to ensure that information flow is more closely governed" is incorrect. MLS can be implemented in TE, but it causes an explosion of types, so its easier to have an additional mechanism. 2.6.1 The discussion on why an access is allowed or denied always starts with TE. In this case, user_t can't alter the clock, nor can it reach the hwclock_t domain since there is no domain transition. -- Chris PeBenito Developer, Hardened Gentoo Linux