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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
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.
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. :^)
Why not remove open from all tty handling. Then confined apps can only
use ttys that are passed to them from parent processes.
Another big change I have put into Fedora policy is the ability to turn
off access to ldap for apps that need auth_use_nsswitch(). (Which turns
out to be just about all confined domains.)
getsebool -a | grep ldap
authlogin_nsswitch_use_ldap --> on
On RHEl6 and all Fedoras you can do this even if the system is using
ldap for passwd, since Fedora and RHEL6 use sssd for authorization and
passwd now.
Other cleanups like turning off unlabelednet.pp, unconfined.pp, While
leaving unconfined_t users, cleaning up corenet_*_all_nodes and
corenet_*all_if need to be done.
But it is very difficult to remove access that was granted, since no one
wants more bugs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2CGdkACgkQrlYvE4MpobOi4ACeMEu26NsyLuMBf2RA20T2ULMg
8K0An0TlyQzP7KBvEF2HV1Wb2rHXU+SY
=Vo9d
-----END PGP SIGNATURE-----
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) ?
> Another big change I have put into Fedora policy is the ability to turn
> off access to ldap for apps that need auth_use_nsswitch(). (Which turns
> out to be just about all confined domains.)
>
> getsebool -a | grep ldap
> authlogin_nsswitch_use_ldap --> on
Yes, I know Redhat is privately putting some effort into tightening
permissions. Although, at a first sight, the overall ratio "+" over "-"
appeared to me always much greater than 1.
> On RHEl6 and all Fedoras you can do this even if the system is using
> ldap for passwd, since Fedora and RHEL6 use sssd for authorization and
> passwd now.
>
> Other cleanups like turning off unlabelednet.pp, unconfined.pp, While
> leaving unconfined_t users, cleaning up corenet_*_all_nodes and
> corenet_*all_if need to be done.
>
> 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...
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.
>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)
...
I'd be very happy to hear from others...
Regards,
Guido
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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) ?
>
>> Another big change I have put into Fedora policy is the ability to turn
>> off access to ldap for apps that need auth_use_nsswitch(). (Which turns
>> out to be just about all confined domains.)
>>
>> getsebool -a | grep ldap
>> authlogin_nsswitch_use_ldap --> on
>
> Yes, I know Redhat is privately putting some effort into tightening
> permissions. Although, at a first sight, the overall ratio "+" over "-"
> appeared to me always much greater than 1.
>
>> On RHEl6 and all Fedoras you can do this even if the system is using
>> ldap for passwd, since Fedora and RHEL6 use sssd for authorization and
>> passwd now.
>>
>> Other cleanups like turning off unlabelednet.pp, unconfined.pp, While
>> leaving unconfined_t users, cleaning up corenet_*_all_nodes and
>> corenet_*all_if need to be done.
>>
>> 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.
> 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 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2COmAACgkQrlYvE4MpobN8XwCfbiWVCj23G00EG+0/1wi0Tj0s
RLMAoI80NQIjACI+MfCrhWBTuS8GUyB9
=8Ik6
-----END PGP SIGNATURE-----
On 03/17/11 12:44, Daniel J Walsh wrote:
> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
>>> On 03/17/2011 09:50 AM, Guido Trentalancia wrote:
>>> 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.
Get me a set of patches that fixes that, and I'll be glad to merge it.
>>> 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.
I think this is the biggest thing point. We've worked hard over many
years to get to a condition where the policy could be used by everyday
users. Do we want a tighter policy? Absolutely. Is there cruft in the
policy? Absolutely. I always push for more documentation so that if
something changes with a particular app that rules could be removed, but
most lines in Refpolicy lack a explanation/justification.
For cases on higher assurance systems, where they do care more about
eliminating this type of access, there is usually rigorous testing
involved already and they have a fairly static configuration. We can't
get an sufficient amount of testing for Refpolicy and the below point is
why.
>> 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.
Definitely. This is probably the biggest issue that we face in
maintaining policy. People do all sorts of things to their systems,
changing configurations and relocating files, etc.
>> 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.
Right. There was ~6 years of policy development that happened before
Refpolicy started and we didn't want to lose the effort that went into
it. The idea being that after a rigorous structure was applied, there
is a better chance of identifying excessive permissions. That did
happen, and we did remove a lot of policy. But its hard finding the
little excessive bits that are sprinkled around the policy.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/17/2011 01:54 PM, Christopher J. PeBenito wrote:
> On 03/17/11 12:44, Daniel J Walsh wrote:
>> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
>>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
>>>> On 03/17/2011 09:50 AM, Guido Trentalancia wrote:
>
>>>> 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.
>
> Get me a set of patches that fixes that, and I'll be glad to merge it.
>
>
I am experimenting with this now. But it would be good if we could
agree on the terminology.
rw_inherited_term_perms is what I am calling it.
And
userdom_use_inherited_term
terminal_use_all_inherited_terminals
>>>> 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.
>
> I think this is the biggest thing point. We've worked hard over many
> years to get to a condition where the policy could be used by everyday
> users. Do we want a tighter policy? Absolutely. Is there cruft in the
> policy? Absolutely. I always push for more documentation so that if
> something changes with a particular app that rules could be removed, but
> most lines in Refpolicy lack a explanation/justification.
>
> For cases on higher assurance systems, where they do care more about
> eliminating this type of access, there is usually rigorous testing
> involved already and they have a fairly static configuration. We can't
> get an sufficient amount of testing for Refpolicy and the below point is
> why.
>
>>> 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.
>
> Definitely. This is probably the biggest issue that we face in
> maintaining policy. People do all sorts of things to their systems,
> changing configurations and relocating files, etc.
>
>>> 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.
>
> Right. There was ~6 years of policy development that happened before
> Refpolicy started and we didn't want to lose the effort that went into
> it. The idea being that after a rigorous structure was applied, there
> is a better chance of identifying excessive permissions. That did
> happen, and we did remove a lot of policy. But its hard finding the
> little excessive bits that are sprinkled around the policy.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2CVDwACgkQrlYvE4MpobPfHQCgnhMiZojP9COPITBtIpTaMK5/
yH4AoLsejYUDEHf+NwYiGMUPzE6PcSI+
=MZ7/
-----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here is a patch against refpolicy that removes most of the opens on
terminals.
http://people.fedoraproject.org/~dwalsh/SELinux/refpolicy_inherited_term.patch
A similar patch on F15 shows
# sesearch -A -t user_devpts_t -p write -c chr_file -C | grep -v ^D | wc -l
180
# sesearch -A -t user_devpts_t -p open -c chr_file -C | grep -v ^D | wc -l
32
# sesearch -A -t user_tty_device_t -p write -c chr_file -C | grep -v ^D
| wc -l
174
# sesearch -A -t user_tty_device_t -p open -c chr_file -C | grep -v ^D
| wc -l
29
# sesearch -A -t tty_device_t -p write -c chr_file -C | grep -v ^D | wc -l
72
# sesearch -A -t tty_device_t -p open -c chr_file -C | grep -v ^D | wc -l
35
The Fedora patch is just tested locally and I will probably wait to put
this fix into F16 since it is kind of dangerous at this point.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2CZcUACgkQrlYvE4MpobO6mACgoB/mXlZJuIebKmdhBIamoba5
ONAAoJ8Cf8XSU/aPjllYFfIMlg3Xwsep
=frjC
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/17/2011 03:40 PM, Guido Trentalancia wrote:
>>> > > 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 ?
>
Right now removing access is difficult, you really need to be able to
start with the entire policy and build. If we improved the tool chain,
you could remove rules. Then people could experiment with removing
rules and it the system still works, suggest patches that remove allow
rules.
Imagine you could write policy module that said
remove application_domain user_tty_device_t:chr_file open;
[SNIP]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2CZyQACgkQrlYvE4MpobM22gCfc8nvGLw359U9yosatI2O/Jg+
n3oAoMzME1s2AY4mfvhF4ng+C0kG1MAF
=p8nx
-----END PGP SIGNATURE-----
On Thu, 17/03/2011 at 13.54 -0400, Christopher J. PeBenito wrote:
> On 03/17/11 12:44, Daniel J Walsh wrote:
> > On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
> >> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
> >>> On 03/17/2011 09:50 AM, Guido Trentalancia wrote:
[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.
>
> I think this is the biggest thing point. We've worked hard over many
> years to get to a condition where the policy could be used by everyday
> users. Do we want a tighter policy? Absolutely. Is there cruft in the
> policy? Absolutely. I always push for more documentation so that if
> something changes with a particular app that rules could be removed, but
> most lines in Refpolicy lack a explanation/justification.
>
> For cases on higher assurance systems, where they do care more about
> eliminating this type of access, there is usually rigorous testing
> involved already and they have a fairly static configuration. We can't
> get an sufficient amount of testing for Refpolicy and the below point is
> why.
>
> >> 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.
>
> Definitely. This is probably the biggest issue that we face in
> maintaining policy. People do all sorts of things to their systems,
> changing configurations and relocating files, etc.
Relocating files is not a problem because the file context could be just
copied off 1:1 from one generation to the next one.
But yes, of course, no doubt it's massive work. One could still rewrite
one module at a time.
But anyway, I was expecting to hear about alternative solutions to
that... For example, Dan proposed to use setools for certain kind of
analysis.
> >> 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.
>
> Right. There was ~6 years of policy development that happened before
> Refpolicy started and we didn't want to lose the effort that went into
> it. The idea being that after a rigorous structure was applied, there
> is a better chance of identifying excessive permissions. That did
> happen, and we did remove a lot of policy. But its hard finding the
> little excessive bits that are sprinkled around the policy.
So when did that happen last ?
And yes, the little excessive bits. Any idea on a method to help
spotting that out ?
Regards,
Guido
On Thu, Mar 17, 2011 at 08:40:04PM +0100, Guido Trentalancia wrote:
> 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).
I think it is more that security is still seen as an expert field, and most
organizations don't have the people or resources to invest in expert fields
beyond using what their vendor is offering. And the investments they do is
more targetting immediate threats like centralized user management, proper
auditing and such. Mandatory Access Control, although offered on all
enterprise-grade platforms, is often disregarded as too difficult to master.
It is a good thing that RedHat and other (commercial) distributions are
(starting to) offer SELinux-enabled systems by default. By integrating it
immediately (and not offering it as an "additional" option) they somewhat
force organizations to at least understand what it does or is supposed to
do. By having the non-commercial distributions focus on SELinux more and
more, this will also create awareness in the community.
Having a working reference policy to start from is an important part here,
because most community distributions don't have the resources to build off
general policies that work for the majority of users themselves. I am
perfectly aware that the reference policy does not entirely do what I would
expect a policy to do on *my* system, but for a distribution, it is a
perfect starting point.
The next step then - once a distribution has at least one policy that is
working well - is to offer the necessary documentation and help for
administrators to create and manage their own policies [1]. After all, if a
distribution only delivers the policy but offers little help to modify or
install your own, then the distributions' the security administrator and not
some team in the organization.
Wkr,
Sven Vermeulen
[1] Not saying that the current distributions don't do this yet (or
sufficiently), this is more of a TODO I'm having here for myself and the
other SELinux helpers in Gentoo ;-)
On Thu, 17/03/2011 at 15.55 -0400, Daniel J Walsh wrote:
> On 03/17/2011 03:40 PM, Guido Trentalancia wrote:
> >>> > > 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 ?
> >
>
> Right now removing access is difficult, you really need to be able to
> start with the entire policy and build. If we improved the tool chain,
> you could remove rules. Then people could experiment with removing
> rules and it the system still works, suggest patches that remove allow
> rules.
Trial and error. Can you think of anything else behind that ? Or
otherwise just confirm that anything else is impossible to achieve ?
Because you know, automated trial and error methods are easy, cheap and
usually quite powerful. But human trial and error can be quite expensive
in practice.
> Imagine you could write policy module that said
>
> remove application_domain user_tty_device_t:chr_file open;
>
> [SNIP]
Yes. I get the point. The operator "remove" always having precedence
over "add". Hopefully we'll have that one day. In the end it shouldn't
be too hard to implement...
You found 1 methodology.
Regards,
Guido
Hi Sven !
On Thu, 17/03/2011 at 21.24 +0100, Sven Vermeulen wrote:
> On Thu, Mar 17, 2011 at 08:40:04PM +0100, Guido Trentalancia wrote:
> > 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).
>
> I think it is more that security is still seen as an expert field, and most
> organizations don't have the people or resources to invest in expert fields
> beyond using what their vendor is offering. And the investments they do is
> more targetting immediate threats like centralized user management, proper
> auditing and such. Mandatory Access Control, although offered on all
> enterprise-grade platforms, is often disregarded as too difficult to master.
I would say most people see security as a very optional, very boring
thing.
It couldn't be otherwise, because (hardening) guidelines such as those
from NSA (for Linux or other OS such Windows) require absolutely no
knowledge about the OS. On Windows, it is really a matter of launching
regedit and a couple of other Microsoft applications and just following
the recommended configuration. On Linux it's just a bit more (editing a
few configuration files maybe). Still many (if not most) people do not
care about investing those 30 minutes...
It's a situation very similar to preventive medicine ("it will never
happen to me").
But I would stop here because perhaps we are getting a bit off-topic
now.
> It is a good thing that RedHat and other (commercial) distributions are
> (starting to) offer SELinux-enabled systems by default. By integrating it
> immediately (and not offering it as an "additional" option) they somewhat
> force organizations to at least understand what it does or is supposed to
> do. By having the non-commercial distributions focus on SELinux more and
> more, this will also create awareness in the community.
Sure.
> Having a working reference policy to start from is an important part here,
> because most community distributions don't have the resources to build off
> general policies that work for the majority of users themselves. I am
> perfectly aware that the reference policy does not entirely do what I would
> expect a policy to do on *my* system, but for a distribution, it is a
> perfect starting point.
Yes.
> The next step then - once a distribution has at least one policy that is
> working well - is to offer the necessary documentation and help for
> administrators to create and manage their own policies [1]. After all, if a
> distribution only delivers the policy but offers little help to modify or
> install your own, then the distributions' the security administrator and not
> some team in the organization.
I think I got lost in the last sentence. But the documentation you
describe is generic documentation about policy writing. So it's
something that could be written once for everybody (ideally a joint
effort).
My question was more about methods for policy reduction and tightening
(a policy management issue)... Can you think about solutions to that
problem ?
Regards,
Guido
On Thu, Mar 17, 2011 at 10:08:44PM +0100, Guido Trentalancia wrote:
> > The next step then - once a distribution has at least one policy that is
> > working well - is to offer the necessary documentation and help for
> > administrators to create and manage their own policies [1]. After all, if a
> > distribution only delivers the policy but offers little help to modify or
> > install your own, then the distributions' the security administrator and not
> > some team in the organization.
>
> I think I got lost in the last sentence. But the documentation you
> describe is generic documentation about policy writing. So it's
> something that could be written once for everybody (ideally a joint
> effort).
True, but some distributions offer additional tools, methods or packages to
support administrators with SELinux.
> My question was more about methods for policy reduction and tightening
> (a policy management issue)... Can you think about solutions to that
> problem ?
I don't have a solution, but my suggestion would be to auditallow the
statements you believe are obsolete for a system and thoroughly test the
system and see if no audits occur.
If you'd like to have the obsoleted ones suggested rather than you having to
find some, perhaps there is a way to regularly dump the avc cache and after
some time, correlate the dumps with the policy, informing the developer
about rules that were potentially never hit during the test.
Little change in method, same principle.
But honestly, I would hope that software developers for which a SELinux
policy (module) exists would maintain it as part of their stack, rather than
rely on people like you to debug, test and suggest updates on the policies.
Wkr,
Sven Vermeulen
On March 17, 2011 15:40 , Guido Trentalancia <[email protected]>
wrote:
> Or even more likely SELinux is still perceived as "difficult to get into"
> (a documentation issue).
My opinion is that SELinux *IS* "difficult to get into"; I do not think
that this is a matter of people holding false perceptions.
This is despite the documentation at
http://fedoraproject.org/wiki/SELinux being very good (in my opinion).
My team also took the RHS429 classroom training, which was also very
good and got us over a large number of hurdles. (As you might guess
from this, I'm a Fedora / RHEL user)
Here is a list of some of the things I think make getting into SELinux
difficult:
- A lot of system administrators are not sufficiently familiar with how
Linux works (in my opinion) -- in particular, system calls, file
handling, session management, device management, networking, processes
-- before they try to get into SELinux. It might be helpful to provide
a list of prerequisites to ensure that
- Effort versus reward: it is VERY easy to disable SELinux to "fix"
something that is "broken" and rarely any negative consequences for
doing so. On the other hand, it can take a lot of time and work to
learn enough to properly fix something while leaving SELinux enabled and
in enforcing mode, with little apparent reward for doing so.
- Terminology. There's a LOT of it to learn. This is not helped by
changes in terminology and confusion regarding domains vs types. On a
semi-related note, there might be too many choices, at least at first:
Modular versus monolithic, targeted versus strict versus MLS;
categories; sensitivities; RBAC; the reference policy. It can be
somewhat overwhelming.
- Part-time versus full-time. I think SELinux is a lot easier if it is
someone's primary focus. However, for system administrators who spend
most of their time managing services and just need to work with SELinux
as a small component of overall service administration, it can be difficult.
For me, personally, I have had the following difficulties:
- I've always struggled with policy file syntax. What is allowed?
Where? The M4 macros make things more mysterious for me, rather than
easier. I'm find having to "pre-declare" everything in a require stanza
to be frustrating, especially as I'm constantly leaving things out.
I've still no understanding of the differences between .if and .te files
(e.g., apache.if versus apache.te in the targeted policy)
- Roles, in particular, could be better documented, in my opinion. At
least, I have not found any great documentation that addresses everyday
situations with roles. I'd like to make more use of roles in order to
run more secure servers, but am a bit lost.
- I've got little to no understanding of what the SELinux code in the
kernel does or how it does it. It's a black box on which I twiddle
knobs and hope I get the result I want. I see AVC denial messages but
have no idea what the Access Vector Cache is.
- Finding and installing the "right" Fedora / Red Hat RPMs for what
needs to be done (e.g., building policies). (It's simple once you know,
but I had a great deal of trouble finding out): setools setools-devel
libsemanage-devel policycoreutils-python selinux-policy-devel
selinux-policy-doc. policycoreutils-python was a big problem for me in
particular here, since the name of the RPM implies -- to me -- that it
is a set of policy core utilities for *use* with python, rather than
tools *written* in python (normally, when installing an RPM, I don't
care about what language was used to write the programs that it contains).
- Overall, I often feel like I'm flailing around in a dimly lit room
hoping to stumble on the solution to my problem-of-the-moment.
- Every so often I look at other MAC systems -- Smack, TOMOYO Linux, App
Armor -- in the hopes that one will provide the benefits of SELinux but
be easier (for me) to understand and work with. No luck yet.
I'm not asking for help or solutions with any of the above bullet points
(I could probably clear up a number of them myself with a few more hours
research), I'm just trying to give people who already understand
everything some insights into people, like me, who are still struggling,
in the hopes that this will be useful to the community as a whole.
Finally, I'd like to thank both Dan Walsh and Dominic Grift for their
blogs -- both blogs have been extremely useful.
--
Mark Montague
mark at catseye.org
Hi Sven !
On Thu, 17/03/2011 at 22.34 +0100, Sven Vermeulen wrote:
> On Thu, Mar 17, 2011 at 10:08:44PM +0100, Guido Trentalancia wrote:
> > > The next step then - once a distribution has at least one policy that is
> > > working well - is to offer the necessary documentation and help for
> > > administrators to create and manage their own policies [1]. After all, if a
> > > distribution only delivers the policy but offers little help to modify or
> > > install your own, then the distributions' the security administrator and not
> > > some team in the organization.
> >
> > I think I got lost in the last sentence. But the documentation you
> > describe is generic documentation about policy writing. So it's
> > something that could be written once for everybody (ideally a joint
> > effort).
>
> True, but some distributions offer additional tools, methods or packages to
> support administrators with SELinux.
>
> > My question was more about methods for policy reduction and tightening
> > (a policy management issue)... Can you think about solutions to that
> > problem ?
>
> I don't have a solution, but my suggestion would be to auditallow the
> statements you believe are obsolete for a system and thoroughly test the
> system and see if no audits occur.
I do not assume anything. In simpler terms, I'd like to scan (search).
> If you'd like to have the obsoleted ones suggested rather than you having to
> find some, perhaps there is a way to regularly dump the avc cache and after
> some time, correlate the dumps with the policy, informing the developer
> about rules that were potentially never hit during the test.
This is cool !
> Little change in method, same principle.
>
> But honestly, I would hope that software developers for which a SELinux
> policy (module) exists would maintain it as part of their stack, rather than
> rely on people like you to debug, test and suggest updates on the policies.
I do not want or plan to do anything like that. But thanks for your
trust anyway !
Are there any developers actually doing that ?
Regards,
Guido
On March 17, 2011 16:24 , Sven Vermeulen <[email protected]> wrote:
> It is a good thing that RedHat and other (commercial) distributions are
> (starting to) offer SELinux-enabled systems by default. By integrating it
> immediately (and not offering it as an "additional" option) they somewhat
> force organizations to at least understand what it does or is supposed to
> do. By having the non-commercial distributions focus on SELinux more and
> more, this will also create awareness in the community.
I agree that it is good that Red Hat and others are offering
SELinux-enabled systems by default.
However, I strongly disagree that this forces organizations to
understand what SELinux does or is supposed to do: In all of the
organizations in which I am personally involved (which includes a major
research University), all of the system administrators I have met
disable SELinux as the very first thing they do after installing the
OS. Most of them disable SELinux without having any real understanding
of what it does, and the reason they give, when asked, is because they
want everything to "just work". When an AVC denial occurs, they don't
even want to know what it means or why it occurs, the just know that
"the AVC denial breaks their service" and disabling SELinux "fixes their
service".
A central security team mandating SELinux could help make headway at the
organizations with whom I work, but I have not had a lot of luck with
them either, as MAC solutions are simply not something they care about
at this time, regardless of platform.
--
Mark Montague
mark at catseye.org
On Thu, Mar 17, 2011 at 07:08:45PM -0400, Mark Montague wrote:
> However, I strongly disagree that this forces organizations to
> understand what SELinux does or is supposed to do: In all of the
> organizations in which I am personally involved (which includes a major
> research University), all of the system administrators I have met
> disable SELinux as the very first thing they do after installing the
> OS. Most of them disable SELinux without having any real understanding
> of what it does, and the reason they give, when asked, is because they
> want everything to "just work". When an AVC denial occurs, they don't
> even want to know what it means or why it occurs, the just know that
> "the AVC denial breaks their service" and disabling SELinux "fixes their
> service".
True, but this is not because security (or SELinux) is boring, it is because
it is considered hard (an expert field).
I hope that the amount of organizations that disable SELinux on first sight
shrinks every day. In the organization I work, they considered SELinux
during the intake of Linux and decided to continue with it, seeing that it
is easier to disable it in exceptional circumstances than enable it in
exceptional circumstances (think DMZ or other).
Wkr,
Sven Vermeulen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/17/2011 11:56 PM, Mark Montague wrote:
> On March 17, 2011 15:40 , Guido Trentalancia <[email protected]>
> wrote:
>> Or even more likely SELinux is still perceived as "difficult to get into"
>> (a documentation issue).
>
> My opinion is that SELinux *IS* "difficult to get into"; I do not think
> that this is a matter of people holding false perceptions.
>
> This is despite the documentation at
> http://fedoraproject.org/wiki/SELinux being very good (in my opinion).
> My team also took the RHS429 classroom training, which was also very
> good and got us over a large number of hurdles. (As you might guess
> from this, I'm a Fedora / RHEL user)
>
> Here is a list of some of the things I think make getting into SELinux
> difficult:
>
> - A lot of system administrators are not sufficiently familiar with how
> Linux works (in my opinion) -- in particular, system calls, file
> handling, session management, device management, networking, processes
> -- before they try to get into SELinux. It might be helpful to provide
> a list of prerequisites to ensure that
>
> - Effort versus reward: it is VERY easy to disable SELinux to "fix"
> something that is "broken" and rarely any negative consequences for
> doing so. On the other hand, it can take a lot of time and work to
> learn enough to properly fix something while leaving SELinux enabled and
> in enforcing mode, with little apparent reward for doing so.
>
> - Terminology. There's a LOT of it to learn. This is not helped by
> changes in terminology and confusion regarding domains vs types.
totally agree and there is a few more of those gotchas. for example how
s0:c1 is one field in the security context tuple although : is used to
signal "new field". So common sense says that s0:c1 are two field but in
reality its a single field.
On a
> semi-related note, there might be too many choices, at least at first:
> Modular versus monolithic, targeted versus strict versus MLS;
> categories; sensitivities; RBAC; the reference policy. It can be
> somewhat overwhelming.
>
> - Part-time versus full-time. I think SELinux is a lot easier if it is
> someone's primary focus. However, for system administrators who spend
> most of their time managing services and just need to work with SELinux
> as a small component of overall service administration, it can be difficult.
>
>
> For me, personally, I have had the following difficulties:
>
> - I've always struggled with policy file syntax. What is allowed?
> Where? The M4 macros make things more mysterious for me, rather than
> easier. I'm find having to "pre-declare" everything in a require stanza
> to be frustrating, especially as I'm constantly leaving things out.
> I've still no understanding of the differences between .if and .te files
> (e.g., apache.if versus apache.te in the targeted policy)
>
> - Roles, in particular, could be better documented, in my opinion. At
> least, I have not found any great documentation that addresses everyday
> situations with roles. I'd like to make more use of roles in order to
> run more secure servers, but am a bit lost.
>
> - I've got little to no understanding of what the SELinux code in the
> kernel does or how it does it. It's a black box on which I twiddle
> knobs and hope I get the result I want. I see AVC denial messages but
> have no idea what the Access Vector Cache is.
>
> - Finding and installing the "right" Fedora / Red Hat RPMs for what
> needs to be done (e.g., building policies). (It's simple once you know,
> but I had a great deal of trouble finding out): setools setools-devel
> libsemanage-devel policycoreutils-python selinux-policy-devel
> selinux-policy-doc. policycoreutils-python was a big problem for me in
> particular here, since the name of the RPM implies -- to me -- that it
> is a set of policy core utilities for *use* with python, rather than
> tools *written* in python (normally, when installing an RPM, I don't
> care about what language was used to write the programs that it contains).
>
> - Overall, I often feel like I'm flailing around in a dimly lit room
> hoping to stumble on the solution to my problem-of-the-moment.
>
> - Every so often I look at other MAC systems -- Smack, TOMOYO Linux, App
> Armor -- in the hopes that one will provide the benefits of SELinux but
> be easier (for me) to understand and work with. No luck yet.
>
> I'm not asking for help or solutions with any of the above bullet points
> (I could probably clear up a number of them myself with a few more hours
> research), I'm just trying to give people who already understand
> everything some insights into people, like me, who are still struggling,
> in the hopes that this will be useful to the community as a whole.
>
> Finally, I'd like to thank both Dan Walsh and Dominic Grift for their
> blogs -- both blogs have been extremely useful.
Thanks. I enjoy guiding people to selinux. It took me many years to get
where i am and i just want to share my knowledge forward. You can also
catch me on #selinux and #fedora-selinux, you will find that i put much
effort into helping people out. If you ask me enough questions you will
know as much as i do.
SELinux is not so hard in my view considering its flexibility. But Linux
is complex and vast.
One issue i think could be better is the description of the object
classes and their descriptions.
In conclusion: managing selinux /security is a specialisation in my
view. Its like a job. Its not just selinux, you also need to know a bit
about security and you need to know about computer systems (linux). To
stay up to date you have to stay up to date with new things (in
linux,selinux and security). Read literature (maillist/irc/blogs) to
keep up to date with any new introduced classes/permissions and other
selinux technologies (and linux and security technologies).
Writing/maintaining selinux policy/systems is always ongoing when you
want optimal control.
The fedora policy/and refpolicy are general purpose policy and its
usually configured by default in a way that is as little invasive as
possible while in the meantime protect as much as possible.
So there are basically two modes:
1. i just accept that its there mode but i do not really care mode.
(novice) (default)
2. i employ selinux and i wield its power as much as possible mode.
(specialist/advanced) (hidden/tunable)
my take
> --
> Mark Montague
> mark at catseye.org
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2DMBsACgkQMlxVo39jgT+x7gCfae7sudsEbiXCipmbJAu2eWQZ
fc0AoJDdTo9cRmiV3YBWYF1tsPuvgM4V
=5NK9
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/18/2011 07:06 AM, Sven Vermeulen wrote:
> On Thu, Mar 17, 2011 at 07:08:45PM -0400, Mark Montague wrote:
>> However, I strongly disagree that this forces organizations to
>> understand what SELinux does or is supposed to do: In all of the
>> organizations in which I am personally involved (which includes a major
>> research University), all of the system administrators I have met
>> disable SELinux as the very first thing they do after installing the
>> OS. Most of them disable SELinux without having any real understanding
>> of what it does, and the reason they give, when asked, is because they
>> want everything to "just work". When an AVC denial occurs, they don't
>> even want to know what it means or why it occurs, the just know that
>> "the AVC denial breaks their service" and disabling SELinux "fixes their
>> service".
>
> True, but this is not because security (or SELinux) is boring, it is because
> it is considered hard (an expert field).
>
> I hope that the amount of organizations that disable SELinux on first sight
> shrinks every day. In the organization I work, they considered SELinux
> during the intake of Linux and decided to continue with it, seeing that it
> is easier to disable it in exceptional circumstances than enable it in
> exceptional circumstances (think DMZ or other).
Good call in my view. That is also my reasoning for removing the
unconfined_domain by default. It is easier to put them in than it is to
remove them without breaking things.
>
> Wkr,
> Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2DMcgACgkQMlxVo39jgT9pmgCgxUXBwPtRx45hc5c8aZ9gToeT
2oYAn2TONszb8TLsSh+84fvsjX6UghNT
=R5ZU
-----END PGP SIGNATURE-----
On Fri, 18/03/2011 at 07.06 +0100, Sven Vermeulen wrote:
> On Thu, Mar 17, 2011 at 07:08:45PM -0400, Mark Montague wrote:
> > However, I strongly disagree that this forces organizations to
> > understand what SELinux does or is supposed to do: In all of the
> > organizations in which I am personally involved (which includes a major
> > research University), all of the system administrators I have met
> > disable SELinux as the very first thing they do after installing the
> > OS. Most of them disable SELinux without having any real understanding
> > of what it does, and the reason they give, when asked, is because they
> > want everything to "just work". When an AVC denial occurs, they don't
> > even want to know what it means or why it occurs, the just know that
> > "the AVC denial breaks their service" and disabling SELinux "fixes their
> > service".
>
> True, but this is not because security (or SELinux) is boring, it is because
> it is considered hard (an expert field).
No, not necessarily, at least in my experience and I am going to explain
why. There are close relatives and close friends of mine that are
professionals (store large amount of sensitive details of customers and
other sensitive and important information) and that when offered
security advice for free on a Sunday afternoon refused it with arguments
similar to the one that I already mentioned for preventive medicine.
This is a general issue with computer security, as the above does not
necessarily refer to Linux.
> I hope that the amount of organizations that disable SELinux on first sight
> shrinks every day. In the organization I work, they considered SELinux
> during the intake of Linux and decided to continue with it, seeing that it
> is easier to disable it in exceptional circumstances than enable it in
> exceptional circumstances (think DMZ or other).
But once again discussing this is outside of the scope of my original
message. Russel Coker has opened a new thread on that on the SELinux
mailing list.
Regards,
Guido
On 03/17/11 14:34, Daniel J Walsh wrote:
> On 03/17/2011 01:54 PM, Christopher J. PeBenito wrote:
>> On 03/17/11 12:44, Daniel J Walsh wrote:
>>> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
>>>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
>>>>> On 03/17/2011 09:50 AM, Guido Trentalancia wrote:
>
>>>>> 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.
>
>> Get me a set of patches that fixes that, and I'll be glad to merge it.
>
>
> I am experimenting with this now. But it would be good if we could
> agree on the terminology.
>
> rw_inherited_term_perms is what I am calling it.
>
> And
>
> userdom_use_inherited_term
> terminal_use_all_inherited_terminals
We can go with this, though I think we should change the rw_term_perms
into use_term_perms for consistency.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 03/17/11 16:15, Guido Trentalancia wrote:
> On Thu, 17/03/2011 at 13.54 -0400, Christopher J. PeBenito wrote:
>> On 03/17/11 12:44, Daniel J Walsh wrote:
>>> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
>>>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
>>>>> On 03/17/2011 09:50 AM, Guido Trentalancia wrote:
>> Right. There was ~6 years of policy development that happened before
>> Refpolicy started and we didn't want to lose the effort that went into
>> it. The idea being that after a rigorous structure was applied, there
>> is a better chance of identifying excessive permissions. That did
>> happen, and we did remove a lot of policy. But its hard finding the
>> little excessive bits that are sprinkled around the policy.
>
> So when did that happen last ?
Its ongoing.
> And yes, the little excessive bits. Any idea on a method to help
> spotting that out ?
If they were easy to find, they would have been removed already. The
point is that its not obvious.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Thu, 2011-03-17 at 18:56 -0400, Mark Montague wrote:
> - I've always struggled with policy file syntax. What is allowed?
> Where? The M4 macros make things more mysterious for me, rather than
> easier. I'm find having to "pre-declare" everything in a require stanza
> to be frustrating, especially as I'm constantly leaving things out.
> I've still no understanding of the differences between .if and .te files
> (e.g., apache.if versus apache.te in the targeted policy)
.if files are for interface/macro definitions. Similar to a header
file.
> - Roles, in particular, could be better documented, in my opinion. At
> least, I have not found any great documentation that addresses everyday
> situations with roles. I'd like to make more use of roles in order to
> run more secure servers, but am a bit lost.
Agreed, but have you looked at:
http://selinuxproject.org/page/RefpolicyBasicRoleCreation
It is far from everything one might want, but at least it is a starting
point.
> - I've got little to no understanding of what the SELinux code in the
> kernel does or how it does it. It's a black box on which I twiddle
> knobs and hope I get the result I want. I see AVC denial messages but
> have no idea what the Access Vector Cache is.
The following is a nice walk through the SELinux kernel code by someone
other than its developers:
http://www.imperialviolet.org/2009/07/14/selinux.html
There are also the official docs:
http://www.nsa.gov/research/selinux/docs.shtml
> - Finding and installing the "right" Fedora / Red Hat RPMs for what
> needs to be done (e.g., building policies). (It's simple once you know,
> but I had a great deal of trouble finding out): setools setools-devel
> libsemanage-devel policycoreutils-python selinux-policy-devel
> selinux-policy-doc. policycoreutils-python was a big problem for me in
> particular here, since the name of the RPM implies -- to me -- that it
> is a set of policy core utilities for *use* with python, rather than
> tools *written* in python (normally, when installing an RPM, I don't
> care about what language was used to write the programs that it contains).
Maybe we need a yum group for all of this? Dan? PolicyDevel or
similar?
--
Stephen Smalley
National Security Agency
On 03/17/11 16:27, Guido Trentalancia wrote:
> On Thu, 17/03/2011 at 15.55 -0400, Daniel J Walsh wrote:
>> On 03/17/2011 03:40 PM, Guido Trentalancia wrote:
>>>>>>> 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 ?
>>>
>>
>> Right now removing access is difficult, you really need to be able to
>> start with the entire policy and build. If we improved the tool chain,
>> you could remove rules. Then people could experiment with removing
>> rules and it the system still works, suggest patches that remove allow
>> rules.
>
> Trial and error. Can you think of anything else behind that ? Or
> otherwise just confirm that anything else is impossible to achieve ?
>
> Because you know, automated trial and error methods are easy, cheap and
> usually quite powerful. But human trial and error can be quite expensive
> in practice.
>
>> Imagine you could write policy module that said
>>
>> remove application_domain user_tty_device_t:chr_file open;
>>
>> [SNIP]
>
> Yes. I get the point. The operator "remove" always having precedence
> over "add". Hopefully we'll have that one day. In the end it shouldn't
> be too hard to implement...
>
> You found 1 methodology.
There has been work on this type of policy functionality. See CIL
efforts in the archive.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 03/17/11 15:40, Guido Trentalancia wrote:
> On Thu, 17/03/2011 at 12.44 -0400, Daniel J Walsh wrote:
>> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
>>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
>> 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).
I think theres two things.
1. People don't actually care about security, especially if it
complicates/hinders what they're trying to do. Most people seek
security measures as a reaction to a security breach.
2. Of the people that have some interest, SELinux is typically seen as
too difficult. We've been working on improving this for years.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 03/17/11 17:34, Sven Vermeulen wrote:
> I don't have a solution, but my suggestion would be to auditallow the
> statements you believe are obsolete for a system and thoroughly test the
> system and see if no audits occur.
>
> If you'd like to have the obsoleted ones suggested rather than you having to
> find some, perhaps there is a way to regularly dump the avc cache and after
> some time, correlate the dumps with the policy, informing the developer
> about rules that were potentially never hit during the test.
This has been considered in the past. The biggest problem is that if
you don't exercise all of the code paths, especially the obscure error
paths, you may be removing valid policy.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
Hello Christopher !
On Fri, 18/03/2011 at 09.45 -0400, Christopher J. PeBenito wrote:
> On 03/17/11 15:40, Guido Trentalancia wrote:
> > On Thu, 17/03/2011 at 12.44 -0400, Daniel J Walsh wrote:
> >> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
> >>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
>
> >> 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).
>
> I think theres two things.
>
> 1. People don't actually care about security, especially if it
> complicates/hinders what they're trying to do. Most people seek
> security measures as a reaction to a security breach.
Typically at that point it would be too late (as opposed to the example
of medicine/health where usually something could still be done).
The second most common reason I have been given (apart from "it will
never happen to me") is in fact: "I am afraid the system would stop
working". At least there is some rationale behind this second reason...
> 2. Of the people that have some interest, SELinux is typically seen as
> too difficult. We've been working on improving this for years.
I think Dominick reply got straight to the point (which applies in
general to MAC strategy not just SELinux):
"SELinux is not so hard in my view considering its flexibility. But
Linux is complex and vast." (Fri, 18 Mar 2011 11:12:43 +0100)
Many people just want to have a piece of software called "anti-virus"
enclosed in beautiful and colored package backed by lots of
advertisement on the public media and such piece of software should tell
them that things are all right most of the time or otherwise that issues
are getting tackled within seconds and that everything will get back to
normality within the same amount of time.
But why are we not moving this discussion to the proper thread started
by Russel on the SELinux mailing list ? My original question had nothing
to do with this, as it was about policy management.
There we could discuss and plan how to improve the documentation
further.
Regards,
Guido
On Fri, 18/03/2011 at 09.52 -0400, Christopher J. PeBenito wrote:
> On 03/17/11 17:34, Sven Vermeulen wrote:
> > I don't have a solution, but my suggestion would be to auditallow the
> > statements you believe are obsolete for a system and thoroughly test the
> > system and see if no audits occur.
> >
> > If you'd like to have the obsoleted ones suggested rather than you having to
> > find some, perhaps there is a way to regularly dump the avc cache and after
> > some time, correlate the dumps with the policy, informing the developer
> > about rules that were potentially never hit during the test.
>
> This has been considered in the past. The biggest problem is that if
> you don't exercise all of the code paths, especially the obscure error
> paths, you may be removing valid policy.
A magic solution to that class of problems does not exist. Similar
drawbacks exist when creating policy for a package that has been written
by somebody else. So there would still need to be some trial and error
part.
Nevertheless, in my opinion that solution is wonderful ! The best answer
I have received so far. A consistent and general methodology.
Regards,
Guido
On Fri, 18/03/2011 at 09.35 -0400, Christopher J. PeBenito wrote:
> On 03/17/11 16:15, Guido Trentalancia wrote:
> > On Thu, 17/03/2011 at 13.54 -0400, Christopher J. PeBenito wrote:
> >> On 03/17/11 12:44, Daniel J Walsh wrote:
> >>> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
> >>>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
> >>>>> On 03/17/2011 09:50 AM, Guido Trentalancia wrote:
>
> >> Right. There was ~6 years of policy development that happened before
> >> Refpolicy started and we didn't want to lose the effort that went into
> >> it. The idea being that after a rigorous structure was applied, there
> >> is a better chance of identifying excessive permissions. That did
> >> happen, and we did remove a lot of policy. But its hard finding the
> >> little excessive bits that are sprinkled around the policy.
> >
> > So when did that happen last ?
>
> Its ongoing.
Is it something that would be scheduled periodically or something that
happens "when possible" with "best effort".
> > And yes, the little excessive bits. Any idea on a method to help
> > spotting that out ?
>
> If they were easy to find, they would have been removed already. The
> point is that its not obvious.
Yes, I know. In fact it is a challenging problem with very few obvious
solutions. That's why I thought it was interesting to discuss it.
Regards,
Guido
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/17/2011 11:56 PM, Mark Montague wrote:
> On March 17, 2011 15:40 , Guido Trentalancia <[email protected]>
> wrote:
>> Or even more likely SELinux is still perceived as "difficult to get into"
>> (a documentation issue).
>
> My opinion is that SELinux *IS* "difficult to get into"; I do not think
> that this is a matter of people holding false perceptions.
>
> This is despite the documentation at
> http://fedoraproject.org/wiki/SELinux being very good (in my opinion).
> My team also took the RHS429 classroom training, which was also very
> good and got us over a large number of hurdles. (As you might guess
> from this, I'm a Fedora / RHEL user)
>
> Here is a list of some of the things I think make getting into SELinux
> difficult:
>
> - A lot of system administrators are not sufficiently familiar with how
> Linux works (in my opinion) -- in particular, system calls, file
> handling, session management, device management, networking, processes
> -- before they try to get into SELinux. It might be helpful to provide
> a list of prerequisites to ensure that
indeed, consider SELinux a tool in the Linux security specialist toolbox
similar to for example a drill in a dentist toolbox for example or a
doctors scalpel.
handling the drill/scalpel itself is probably easy too learn, but if you
do not have knowledge about tooth, root canals, human body, where to
drill or make an incision and i do not know what other aspects, then
chances are you will still be confused, insecure and prone to make errors.
i feel pretty confident with SELinux, but that is only part of the job.
My weak spots are my lack of security background and lack of programming
background.
It is a pretty serious problem that i try to work on.
> - Effort versus reward: it is VERY easy to disable SELinux to "fix"
> something that is "broken" and rarely any negative consequences for
> doing so. On the other hand, it can take a lot of time and work to
> learn enough to properly fix something while leaving SELinux enabled and
> in enforcing mode, with little apparent reward for doing so.
>
> - Terminology. There's a LOT of it to learn. This is not helped by
> changes in terminology and confusion regarding domains vs types. On a
> semi-related note, there might be too many choices, at least at first:
> Modular versus monolithic, targeted versus strict versus MLS;
> categories; sensitivities; RBAC; the reference policy. It can be
> somewhat overwhelming.
>
> - Part-time versus full-time. I think SELinux is a lot easier if it is
> someone's primary focus. However, for system administrators who spend
> most of their time managing services and just need to work with SELinux
> as a small component of overall service administration, it can be difficult.
>
>
> For me, personally, I have had the following difficulties:
>
> - I've always struggled with policy file syntax. What is allowed?
> Where? The M4 macros make things more mysterious for me, rather than
> easier. I'm find having to "pre-declare" everything in a require stanza
> to be frustrating, especially as I'm constantly leaving things out.
> I've still no understanding of the differences between .if and .te files
> (e.g., apache.if versus apache.te in the targeted policy)
>
> - Roles, in particular, could be better documented, in my opinion. At
> least, I have not found any great documentation that addresses everyday
> situations with roles. I'd like to make more use of roles in order to
> run more secure servers, but am a bit lost.
>
> - I've got little to no understanding of what the SELinux code in the
> kernel does or how it does it. It's a black box on which I twiddle
> knobs and hope I get the result I want. I see AVC denial messages but
> have no idea what the Access Vector Cache is.
>
> - Finding and installing the "right" Fedora / Red Hat RPMs for what
> needs to be done (e.g., building policies). (It's simple once you know,
> but I had a great deal of trouble finding out): setools setools-devel
> libsemanage-devel policycoreutils-python selinux-policy-devel
> selinux-policy-doc. policycoreutils-python was a big problem for me in
> particular here, since the name of the RPM implies -- to me -- that it
> is a set of policy core utilities for *use* with python, rather than
> tools *written* in python (normally, when installing an RPM, I don't
> care about what language was used to write the programs that it contains).
>
> - Overall, I often feel like I'm flailing around in a dimly lit room
> hoping to stumble on the solution to my problem-of-the-moment.
>
> - Every so often I look at other MAC systems -- Smack, TOMOYO Linux, App
> Armor -- in the hopes that one will provide the benefits of SELinux but
> be easier (for me) to understand and work with. No luck yet.
>
> I'm not asking for help or solutions with any of the above bullet points
> (I could probably clear up a number of them myself with a few more hours
> research), I'm just trying to give people who already understand
> everything some insights into people, like me, who are still struggling,
> in the hopes that this will be useful to the community as a whole.
>
> Finally, I'd like to thank both Dan Walsh and Dominic Grift for their
> blogs -- both blogs have been extremely useful.
>
> --
> Mark Montague
> mark at catseye.org
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2DfD8ACgkQMlxVo39jgT8UuQCfYTGmKJeEViNR6gty+X+VAAgG
i38An0PdwPTtnvpXIfR3itmrBb11x1Ro
=yQtB
-----END PGP SIGNATURE-----
Hello again Christopher !
On Fri, 18/03/2011 at 09.45 -0400, Christopher J. PeBenito wrote:
> On 03/17/11 15:40, Guido Trentalancia wrote:
> > On Thu, 17/03/2011 at 12.44 -0400, Daniel J Walsh wrote:
> >> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
> >>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
>
> >> 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).
>
> I think theres two things.
>
> 1. People don't actually care about security, especially if it
> complicates/hinders what they're trying to do. Most people seek
> security measures as a reaction to a security breach.
> 2. Of the people that have some interest, SELinux is typically seen as
> too difficult. We've been working on improving this for years.
I have an idea.
Things will probably improve considerably if you manage to set up two
separate mailing lists: one for the end-users and one for the
developers. This mailing list will coincide with the latter.
This is common practice in open source software. The cost is minimal
(reconfiguration of an existing mailing list server and update of a few
existing web pages and documents).
Most of the time users are facing common issues and could help each
other. Archived message would make a knowledge base. Developers could
voluntarily spare some time on the end-user mailing list and at the same
time could benefit from important feedback that is not an explicit bug
report.
Of course the same could be done for SELinux with similar benefits and
cost.
Regards,
Guido
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/18/2011 01:14 PM, Guido Trentalancia wrote:
> Hello again Christopher !
>
> On Fri, 18/03/2011 at 09.45 -0400, Christopher J. PeBenito wrote:
>> On 03/17/11 15:40, Guido Trentalancia wrote:
>>> On Thu, 17/03/2011 at 12.44 -0400, Daniel J Walsh wrote:
>>>> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
>>>>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
>>
>>>> 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).
>>
>> I think theres two things.
>>
>> 1. People don't actually care about security, especially if it
>> complicates/hinders what they're trying to do. Most people seek
>> security measures as a reaction to a security breach.
>> 2. Of the people that have some interest, SELinux is typically seen as
>> too difficult. We've been working on improving this for years.
>
> I have an idea.
>
> Things will probably improve considerably if you manage to set up two
> separate mailing lists: one for the end-users and one for the
> developers. This mailing list will coincide with the latter.
>
> This is common practice in open source software. The cost is minimal
> (reconfiguration of an existing mailing list server and update of a few
> existing web pages and documents).
>
> Most of the time users are facing common issues and could help each
> other. Archived message would make a knowledge base. Developers could
> voluntarily spare some time on the end-user mailing list and at the same
> time could benefit from important feedback that is not an explicit bug
> report.
>
> Of course the same could be done for SELinux with similar benefits and
> cost.
>
> Regards,
>
> Guido
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
There is a fairly active list for SELinux users although distribution
specific
selinux at lists.fedoraproject.org
I also monitor most other Fedora users lists for mention of SELinux.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2DpycACgkQrlYvE4MpobM40gCg1nZihX77gTxiW6QdmwXkb+fr
eEIAnR74UQIsVd69ZXR/q1XwJWovM1cu
=AwtB
-----END PGP SIGNATURE-----
On Fri, 18/03/2011 at 14.40 -0400, Daniel J Walsh wrote:
> On 03/18/2011 01:14 PM, Guido Trentalancia wrote:
> > Hello again Christopher !
> >
> > On Fri, 18/03/2011 at 09.45 -0400, Christopher J. PeBenito wrote:
> >> On 03/17/11 15:40, Guido Trentalancia wrote:
> >>> On Thu, 17/03/2011 at 12.44 -0400, Daniel J Walsh wrote:
> >>>> On 03/17/2011 12:04 PM, Guido Trentalancia wrote:
> >>>>> On Thu, 17/03/2011 at 10.25 -0400, Daniel J Walsh wrote:
> >>
> >>>> 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).
> >>
> >> I think theres two things.
> >>
> >> 1. People don't actually care about security, especially if it
> >> complicates/hinders what they're trying to do. Most people seek
> >> security measures as a reaction to a security breach.
> >> 2. Of the people that have some interest, SELinux is typically seen as
> >> too difficult. We've been working on improving this for years.
> >
> > I have an idea.
> >
> > Things will probably improve considerably if you manage to set up two
> > separate mailing lists: one for the end-users and one for the
> > developers. This mailing list will coincide with the latter.
> >
> > This is common practice in open source software. The cost is minimal
> > (reconfiguration of an existing mailing list server and update of a few
> > existing web pages and documents).
> >
> > Most of the time users are facing common issues and could help each
> > other. Archived message would make a knowledge base. Developers could
> > voluntarily spare some time on the end-user mailing list and at the same
> > time could benefit from important feedback that is not an explicit bug
> > report.
> >
> > Of course the same could be done for SELinux with similar benefits and
> > cost.
> >
> > Regards,
> >
> > Guido
> >
> There is a fairly active list for SELinux users although distribution
> specific
>
> selinux at lists.fedoraproject.org
>
> I also monitor most other Fedora users lists for mention of SELinux.
For SELinux it would probably be equivalent because of the little
differences in the standard tools. But when it comes to the policy
perhaps there are major differences as all the patches that I have seen
on different distributions are usually quite heavy and specific...
I don't know, it was just an idea.