From: guido@trentalancia.com (Guido Trentalancia)
Date: Tue, 01 Mar 2011 21:32:38 +0100
Subject: [refpolicy] [patch 1/3] Implementation of system conf type
In-Reply-To: <4D6D507C.2040906@tresys.com>
References: <4D5E95C1.9080805@redhat.com>  <20110219095711.GA6270@siphos.be>
	<1298180267.3098.11.camel@tesla.lan>  <4D62875A.8060006@redhat.com>
	<1298319075.11119.3.camel@tesla.lan>  <4D63DA61.3050705@tresys.com>
	<1298392040.16004.15.camel@tesla.lan>  <4D6D507C.2040906@tresys.com>
Message-ID: <1299011558.14035.29.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, 01/03/2011 at 15.01 -0500, Christopher J. PeBenito wrote:
> On 02/22/11 11:27, Guido Trentalancia wrote:
> > Hello again Christopher !
> > 
> > On Tue, 22/02/2011 at 10.46 -0500, Christopher J. PeBenito wrote:
> >> On 02/21/11 15:11, Guido Trentalancia wrote:
> >>> On Mon, 21/02/2011 at 10.40 -0500, Daniel J Walsh wrote:
> >>>> On 02/20/2011 12:37 AM, Guido Trentalancia wrote:
> >>>>> On Sat, 19/02/2011 at 10.57 +0100, Sven Vermeulen wrote:
> >>>>>> On Fri, Feb 18, 2011 at 03:52:33PM +0000, Miroslav Grepl wrote:
> >>>>>>> http://mgrepl.fedorapeople.org/F15/system_conf_implemantion_p1.patch
> >>>>>>>
> >>>>>>>      * Implementation of system conf type for manageable system 
> >>>>>>> configuration files.
> >>>>>>
> >>>>>> Isn't a generic system configuration type a bit too broad for a security
> >>>>>> policy? We already have etc_t.
> >>>>>
> >>>>> I agree with Sven, it appears to be rather useless (at least for the use
> >>>>> that is being made so far in the patches that have been posted) and it
> >>>>> just introduces a redundancy of types.
> >>>>>
> >>>>> But Sven, I believe this is stuff just intended for Fedora 15. It won't
> >>>>> affect the rest of us. I don't even understand why it has been posted
> >>>>> with the [PATCH] tag in the subject on this mailing list. Some stuff
> >>>>> won't even build on refpolicy because there are missing bits (such as
> >>>>> missing interfaces that have never been defined in refpolicy and that
> >>>>> are only being used by Fedora as part of their customisations).
> >>>>>
> >>>>
> >>>> When you have a type a domain needs to write, you do not want that type
> >>>> to be etc_t.  In this case several confined domains needs to be able to
> >>>> write firewall rules, I believe.  If we give tools like
> >>>> system-config-firewall the ability to write etc_t, it can replace
> >>>> /etc/passwd and other key config files.  So an exploit can be used to
> >>>> take over the entire machine, if we add a new type, then
> >>>> system-config-firewall will only be allowed to write firewall rules and
> >>>> not most files within the /etc tree.
> >>
> >> I am against system_conf_t as it is too generic.  Yes, we'd like to curb
> >> writing to etc_t.  But creating another generic type is not the answer.
> >>  In a year or two, we'd be in the same boat except with system_conf_t
> >> instead of (or maybe in addition to) etc_t.
> > 
> > However, a label for configuration files that tweak kernel parameters
> > could be a nice thing to have. So, it would not be generic. And it could
> > bring security benefits, as kernel parameters are critical.
> > 
> > Something like kernel_conf_t ? That could be used for Fedora's sysconf
> > (if it has something to do with kernel parameters),
> > Debian's /etc/sysctl.conf and so on. It could be used for things such as
> > grub that also has kernel boot parameters.
> 
> What other examples are there other than sysctl.conf?  If there are
> none, then we could consider sysctl_conf_t, but I don't know of a reason
> for anyone other than the sysadmin or the package manager for modifying
> that file.  Both are trusted to handle etc_t.

First of all I am not sure that that this system conf from Fedora 15 has
anything to do with kernel parameters or is something similar to
sysctl.conf on Debian.

And for sure this is not something that is needed right now.

On the other hand, having a separate label for sysctl.conf (and anything
similar to sysctl.conf on other distributions) would be an investment
for the future if one day somebody develops an application that needs to
write those files (either interactively or automatically). At that
point, the policy needs to specify who is allowed to write those files
which would be treated for what they are and not as generic etc_t files.

An example of such application could be a graphical system
administration tool (an interactive tool) that can be used not only by
sysadm but also by others. Such tool could then modify the new file type
but not /etc/passwd or /etc/bashrc.

In my opinion, in the current situation there is very little benefit
from having that (other than being "future-proof").

Regards,

Guido