From: guido@trentalancia.com (Guido Trentalancia) Date: Thu, 17 Mar 2011 20:40:04 +0100 Subject: [refpolicy] Question: and the policy grows... In-Reply-To: <4D823A60.9020107@redhat.com> References: <1300369855.30425.14.camel@tesla.lan> <4D8219D9.7080504@redhat.com> <1300377867.30425.40.camel@tesla.lan> <4D823A60.9020107@redhat.com> Message-ID: <1300390804.31755.6.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Thu, 17/03/2011 at 12.44 -0400, Daniel J Walsh wrote: > On 03/17/2011 12:04 PM, Guido Trentalancia wrote: > > Hello Dan, > > > > thanks very much for getting back ! > > > > On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote: > >> On 03/17/2011 09:50 AM, Guido Trentalancia wrote: > >>> Hello everybody ! > >>> > >>> I have a question which I believe is quite interesting. > >>> > >>> I often get on and off the list because of a lack of time, but I have > >>> noticed that most (if not all) of the patches that have been submitted > >>> to refpolicy in the last period of time, including a few patches that I > >>> have submitted, were intended to improve usability and were going to add > >>> new permissions to this or that policy module (it's always diff +). > >>> > >>> So, the policy grows... and becomes weaker (less tight and secure), > >>> although hopefully more usable. > >>> > >>> If this trends continues the policy will just become weaker and weaker > >>> with time and this might not always be backed by an increased usability. > >>> > >>> I would even expect that some of the permissions added long time ago and > >>> still present in the policy are no longer needed by more recent versions > >>> of the same packages. And usually backwards compatibility (for very old > >>> package versions) is not something which should be guaranteed forever... > >>> > >>> So my question is: who is going to take care of periodically trimming > >>> down the permissions in refpolicy that are no longer needed (keep the > >>> policy tight) ? But more importantly how is this going to be done > >>> technically (the methodology) ? > >>> > >>> Thanks for your time ! > >>> > >>> Regards, > >>> > >>> Guido > >>> > >> Great question. I think one problem we have is that refpolicy is a one > >> size fits all system. Upstream has decided to maintain policy in such a > >> way that it would continue to work on Ancient distributions (RHEL4), So > >> removing Access could break older distributions. > >> > >> On thing that refpolicy has not adopted is the use of inherited file > >> descriptors versus files descriptors opened by applications. > >> > >> For example, we have lots of code that allows confined applications to > >> open terminals. I would bet that almost no confined processes ever open > >> a terminal. And yet the ability to open a terminal can give you a > >> communications channel to attack other confined processes or even the > >> confined user. > > > > Great example. > > > >> If you put the prompt passwd: in front of me in a terminal, my fingers > >> will type my password before my brain can stop them. :^) > > > > That's too true ! > > > >> Why not remove open from all tty handling. Then confined apps can only > >> use ttys that are passed to them from parent processes. > > > > Good idea. But will that always be applicable (without changing the > > application or imposing anything to application developers) ? [cut] > >> But it is very difficult to remove access that was granted, since no one > >> wants more bugs. > > > > There might be environments where a (temporary) bug is always preferable > > than a looser policy... > > > Well as long as the temporary bug does not cause someone to disable SELinux. What I meant is environments where SELinux cannot be disabled. Where limited or even no functionality is always preferable to a looser/risky policy. > > In any case, we haven't found a solution (or at least a methodology). > > The only (obvious) one I can foresee at the moment is periodically > > restarting from scratch (i.e. creating a new generation of refpolicy > > from scratch every x years). Which is massive work. > > > Yes and going to generate a large amount of errors, since most bugs are > caused by running apps in different ways. > > > From the Changelog I take that refpolicy started on June 2005. Software > > version numbers does not necessarily mean anything, but just to give an > > idea, on June 2005, we had the following versions (taken at random): > > > > kernel 2.6.12 (now 2.6.38) > > Linux-PAM 0.79 (now 1.1.3) > > gtk+ 2.6.8 (now 3.0) > > evolution 2.3.3 (now 2.32.2) > > ... > And refpolicy was an attempt to make all rules == example policy when > the port happened, so most of the original rules come from Prior to 2002. > > > > I'd be very happy to hear from others... > > > > Regards, > > > > Guido > > > I think if we ever get to the next generation of policy and could start > removing rules. easily this would help. I didn't get this. What could help ? > I think people going through with setools and looking for unexpected > allow rules would be helpful. > > setools is a pretty good set of tools for analyzing policy. If we could > get some people (college kids) to analyze the policy. And then open > bugs where they think we have wholes. > > # sesearch -A -t user_tty_device_t -p open | wc -l > 254 > > On a system where unconfind.pp is disabled we still have 254 domains > that can open a users tty in Fedora 15 > > sesearch -A -t shadow_t -c file -p open -C | grep -v ^D | wc -l > 23 > > sesearch -A -t passwd_t -c process -p transition | wc -l > 13 > > I think getting people to go in and examine the policy and ask > questions, why do we have these rules would be helpful. Maybe we setup > test days, or something to remove bogus policy. There is at least the limit of not having many people on this list compared to most other Linux projects. Perhaps security is considered something boring to the average user/developer. Or even more likely SELinux is still perceived as "difficult to get into" (a documentation issue). Regards, Guido