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 1PeWwA-0001KB-Gc for garchives@archives.gentoo.org; Sun, 16 Jan 2011 18:02:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1D06BE088F for ; Sun, 16 Jan 2011 18:02:45 +0000 (UTC) Received: from mail.aoaforums.com (www.aoaforums.com [174.123.188.106]) by pigeon.gentoo.org (Postfix) with ESMTP id E4731E0BD7 for ; Sun, 16 Jan 2011 17:06:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.aoaforums.com (Postfix) with ESMTP id 5C92ABB4CA for ; Sun, 16 Jan 2011 17:06:50 +0000 (GMT) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.aoaforums.com 5C92ABB4CA DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=giz-works.com; s=20080229-giz-works-com; t=1295197610; bh=ZsWWs/FL/GJQDJDdWFd13q9qiSU=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gET6iNNidCRwrdlyvJzCBLXZHZ3jDFew8jy10wEJrZZwyMbkiSye4PExbsbir0MQK cHNOTky4opxQDAlE2yzDo4osj7LngAEp0/v+fgRezhR53DbRICAbtiHI8fLoD6R3vl 2KWeONvQECDJLZms+5pWKHGLgRl5AxR4Hp8d9TuU= X-Virus-Scanned: amavisd-new at aoaforums.com Received: from mail.aoaforums.com ([127.0.0.1]) by localhost (aoaforums.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7TZa+nZAd+b for ; Sun, 16 Jan 2011 17:06:48 +0000 (GMT) Received: from [10.0.0.17] (adsl-70-134-53-63.dsl.spfdmo.swbell.net [70.134.53.63]) by mail.aoaforums.com (Postfix) with ESMTPSA id 75FA53D453 for ; Sun, 16 Jan 2011 17:06:48 +0000 (GMT) Message-ID: <4D3325A7.5080101@giz-works.com> Date: Sun, 16 Jan 2011 11:06:47 -0600 From: Chris Richards User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 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: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] SELinux policy rules principles? References: <20110116150950.GA17577@siphos.be> In-Reply-To: <20110116150950.GA17577@siphos.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: b190b5fe-9b32-48b2-9baa-a5815beada59 X-Archives-Hash: 1f98f4e19056cf58cd74d74078d39543 On 01/16/2011 09:09 AM, Sven Vermeulen wrote: > Hi all, > > When writing security policies, it is important to first have a vision on > how the security policies should be made. Of course, final vision should be > with a systems' security administrator, but a distribution should give a > first start for this. > > For the time being, Gentoo Hardened's policies are based upon the reference > policy's implementation, but I can imagine that this will evolve further. > The moment however we start adding policies ourselves (outside simple > patching of the reference policy's implementation) we need to have some > rules on what or how our rules should be made. > > One first principle that we might need to discuss about is what we want to > allow in our policy. Do we want to allow all normal behavior (i.e. you use > an application or server the way it is meant to and we make sure no denials > are generated for this) but shield off abnormal behavior as much as possible > (by rightly aligning domains and types)? Or do we want to allow just enough > so that the applications function properly during regular operations, > causing various denials to be in place still? My general feeling is that the system should operate FROM THE USER PERSPECTIVE the way it always does, i.e. the existence of SELinux should be relatively transparent to the user and/or administrator, at least to the extent that is practical. There may be some things that you simply can't avoid changing, but they should generally be few and far between. > And if we would opt for the latter, do we want to dontaudit those denials to > keep the logging clean, or do we then expect the administrator to manage his > own dontaudits? > My general feeling here is that, again where practical, we should avoid cluttering the logs. Logs that are cluttered with noise don't get properly evaluated for the truly exceptional conditions that the administrator needs to be concerned about. Obviously, there are tools that can help with this, but those tools should be used for the purpose of helping the administrator organize the information, not prune the logs of stuff to ignore. If there's stuff that is going to be routinely ignored because it is essentially useless chatter, then it shouldn't be there to start with. Those are just my thoughts. Others who know more than I may have a different opinion. Later, Chris