[refpolicy] Question: and the policy grows...

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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] Question: and the policy grows...

[Daniel J Walsh]

-----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-----

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] Question: and the policy grows...

[Daniel J Walsh]

-----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-----

[refpolicy] Question: and the policy grows...

[Christopher J. PeBenito]

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
www.tresys.com | oss.tresys.com

[refpolicy] Question: and the policy grows...

[Daniel J Walsh]

-----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-----

[refpolicy] Question: and the policy grows...

[Daniel J Walsh]

-----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-----

[refpolicy] Question: and the policy grows...

[Christopher J. PeBenito]

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
www.tresys.com | oss.tresys.com

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] Question: and the policy grows...

[Christopher J. PeBenito]

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
www.tresys.com | oss.tresys.com

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] Question: and the policy grows...

[Daniel J Walsh]

-----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-----

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] Question: and the policy grows...

[Christopher J. PeBenito]

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
www.tresys.com | oss.tresys.com

[refpolicy] Question: and the policy grows...

[Sven Vermeulen]

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 ;-)

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] Question: and the policy grows...

[Sven Vermeulen]

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

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] Question: and the policy grows...

[Christopher J. PeBenito]

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
www.tresys.com | oss.tresys.com

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] Question: and the policy grows...

[Mark Montague]

  On March 17, 2011 16:24 , Sven Vermeulen <sven.vermeulen@siphos.be> 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

[refpolicy] Question: and the policy grows...

[Sven Vermeulen]

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

[refpolicy] Question: and the policy grows...

[Dominick Grift]

-----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-----

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] Question: and the policy grows...

[Mark Montague]

  On March 17, 2011 15:40 , Guido Trentalancia <guido@trentalancia.com> 
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

[refpolicy] Question: and the policy grows...

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/17/2011 11:56 PM, Mark Montague wrote:
>   On March 17, 2011 15:40 , Guido Trentalancia <guido@trentalancia.com> 
> 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-----

[refpolicy] Question: and the policy grows...

[Stephen Smalley]

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

[refpolicy] Question: and the policy grows...

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/17/2011 11:56 PM, Mark Montague wrote:
>   On March 17, 2011 15:40 , Guido Trentalancia <guido@trentalancia.com> 
> 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-----

SE Linux use - was: Question: and the policy grows...

[Russell Coker]

On Fri, 18 Mar 2011, Guido Trentalancia <guido@trentalancia.com> 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).

NSA people:  How many subscribers are there to this list outside .gov?

Tresys people:  How many subscribers to the refpolicy list are outside .gov?

Does anyone know of a good study about the size of typical Linux projects?  
I'm willing to bet that SE Linux has more active developers and more members 
on the main mailing list than most Linux projects.

On Fri, 18 Mar 2011, Sven Vermeulen <sven.vermeulen@siphos.be> 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.

Red Hat has been doing it for a long time, since RHEL4 (they are at RHEL6 
now).

Making it a default feature means that if a server is cracked and it turns out 
to have had SE Linux disabled then the sysadmin will have to explain why they 
turned off default security features thus making it easier for the attacker.  
That wouldn't be a desirable situation for a sysadmin to be in.

http://oss.tresys.com/pipermail/refpolicy/2011-March/004129.html

Mark Montague's message archived at the above URL is worth bookmarking as a 
list of issues to work on.

On Fri, 18 Mar 2011, Mark Montague <mark@catseye.org> wrote:
> 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".

There are a lot of people who do the same with UID and GID, they just run 
everything as root.  Nearly as bad are the people who run everything as user 
"nobody", so "nobody" becomes everybody which dramatically weakens security.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Guido Trentalancia]

Hi Russel !

On Fri, 18/03/2011 at 10.24 +1100, Russell Coker wrote:
> On Fri, 18 Mar 2011, Guido Trentalancia <guido@trentalancia.com> 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).
> 
> NSA people:  How many subscribers are there to this list outside .gov?
> 
> Tresys people:  How many subscribers to the refpolicy list are outside .gov?
> 
> Does anyone know of a good study about the size of typical Linux projects?  
> I'm willing to bet that SE Linux has more active developers and more members 
> on the main mailing list than most Linux projects.

In that context I meant active subscribers.

I found an estimate for Gnome (gnome.org):

around 700 active committers in the last two years

cfr.
http://www.osor.eu/idabc-studies/expert-docs/encouraging-good-practice

Just showed up as the very first results on Google.

> On Fri, 18 Mar 2011, Sven Vermeulen <sven.vermeulen@siphos.be> 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.
> 
> Red Hat has been doing it for a long time, since RHEL4 (they are at RHEL6 
> now).
> 
> Making it a default feature means that if a server is cracked and it turns out 
> to have had SE Linux disabled then the sysadmin will have to explain why they 
> turned off default security features thus making it easier for the attacker.  
> That wouldn't be a desirable situation for a sysadmin to be in.
> 
> http://oss.tresys.com/pipermail/refpolicy/2011-March/004129.html
> 
> Mark Montague's message archived at the above URL is worth bookmarking as a 
> list of issues to work on.
> 
> On Fri, 18 Mar 2011, Mark Montague <mark@catseye.org> wrote:
> > 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".
> 
> There are a lot of people who do the same with UID and GID, they just run 
> everything as root.  Nearly as bad are the people who run everything as user 
> "nobody", so "nobody" becomes everybody which dramatically weakens security.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Jason Axelson]

On Thu, Mar 17, 2011 at 1:24 PM, Russell Coker <russell@coker.com.au> wrote:
> Does anyone know of a good study about the size of typical Linux projects?
> I'm willing to bet that SE Linux has more active developers and more members
> on the main mailing list than most Linux projects.

For looking at active developers/contributers to a project, ohloh.net
has some interesting tools. Unfortunately the SELinux project on the
site doesn't point to the main repo and refpolicy doesn't seem to be
on there either.

But it is interesting to use ohloh to look at various other projects
to easily see how active they are and how many people are contributing
code to.

Also, ohloh is user editable so someone could fix it up if they felt
so inclined.

https://www.ohloh.net/p/selinux/contributors

Jason

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[James Carter]

On Fri, 2011-03-18 at 10:24 +1100, Russell Coker wrote:
> On Fri, 18 Mar 2011, Guido Trentalancia <guido@trentalancia.com> 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).
> 
> NSA people:  How many subscribers are there to this list outside .gov?
> 

887

There are 30 people who have posted 10 or more messages in the last
year.

> Tresys people:  How many subscribers to the refpolicy list are outside .gov?
> 
> Does anyone know of a good study about the size of typical Linux projects?  
> I'm willing to bet that SE Linux has more active developers and more members 
> on the main mailing list than most Linux projects.
> 
> On Fri, 18 Mar 2011, Sven Vermeulen <sven.vermeulen@siphos.be> 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.
> 
> Red Hat has been doing it for a long time, since RHEL4 (they are at RHEL6 
> now).
> 
> Making it a default feature means that if a server is cracked and it turns out 
> to have had SE Linux disabled then the sysadmin will have to explain why they 
> turned off default security features thus making it easier for the attacker.  
> That wouldn't be a desirable situation for a sysadmin to be in.
> 
> http://oss.tresys.com/pipermail/refpolicy/2011-March/004129.html
> 
> Mark Montague's message archived at the above URL is worth bookmarking as a 
> list of issues to work on.
> 
> On Fri, 18 Mar 2011, Mark Montague <mark@catseye.org> wrote:
> > 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".
> 
> There are a lot of people who do the same with UID and GID, they just run 
> everything as root.  Nearly as bad are the people who run everything as user 
> "nobody", so "nobody" becomes everybody which dramatically weakens security.
> 

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Russell Coker]

On Sat, 19 Mar 2011, James Carter <jwcart2@tycho.nsa.gov> wrote:
> > NSA people:  How many subscribers are there to this list outside .gov?
> >
> > 
> 
> 887
> 
> There are 30 people who have posted 10 or more messages in the last
> year.

On Sat, 19 Mar 2011, "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
> > Tresys people:  How many subscribers to the refpolicy list are outside
> > .gov?
> 
> 95

Any theories as to why are there almost 10* more people on the main list?

It seems to me that policy development is easier to get involved with than all 
other types of SE Linux development, and it's more required.  One can do a lot 
of SE Linux work without touching any of the C code, but it's not possible to 
do much outside the distribution defaults without writing some policy.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Christopher J. PeBenito]

On 03/18/11 10:33, Russell Coker wrote:
> On Sat, 19 Mar 2011, James Carter <jwcart2@tycho.nsa.gov> wrote:
>>> NSA people:  How many subscribers are there to this list outside .gov?
>>>
>>>
>>
>> 887
>>
>> There are 30 people who have posted 10 or more messages in the last
>> year.
> 
> On Sat, 19 Mar 2011, "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
>>> Tresys people:  How many subscribers to the refpolicy list are outside
>>> .gov?
>>
>> 95
> 
> Any theories as to why are there almost 10* more people on the main list?
> 
> It seems to me that policy development is easier to get involved with than all 
> other types of SE Linux development, and it's more required.  One can do a lot 
> of SE Linux work without touching any of the C code, but it's not possible to 
> do much outside the distribution defaults without writing some policy.

My assumption is that most people don't care about all of the policy
maintenance minutiae and don't want to be flooded with the patch emails.
 But on the main list you can find out about the development direction
and functionality changes; IMO thats why only ~3% of the subscribers
constitute the majority of the list traffic.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Guido Trentalancia]

On Fri, 18/03/2011 at 10.57 -0400, Christopher J. PeBenito wrote:
> On 03/18/11 10:33, Russell Coker wrote:
> > On Sat, 19 Mar 2011, James Carter <jwcart2@tycho.nsa.gov> wrote:
> >>> NSA people:  How many subscribers are there to this list outside .gov?
> >>>
> >>>
> >>
> >> 887
> >>
> >> There are 30 people who have posted 10 or more messages in the last
> >> year.
> > 
> > On Sat, 19 Mar 2011, "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
> >>> Tresys people:  How many subscribers to the refpolicy list are outside
> >>> .gov?
> >>
> >> 95
> > 
> > Any theories as to why are there almost 10* more people on the main list?
> > 
> > It seems to me that policy development is easier to get involved with than all 
> > other types of SE Linux development, and it's more required.  One can do a lot 
> > of SE Linux work without touching any of the C code, but it's not possible to 
> > do much outside the distribution defaults without writing some policy.
> 
> My assumption is that most people don't care about all of the policy
> maintenance minutiae and don't want to be flooded with the patch emails.
>  But on the main list you can find out about the development direction
> and functionality changes; IMO thats why only ~3% of the subscribers
> constitute the majority of the list traffic.

It still sounds strange to me. In the very end, what actually implements
security is the policy...

Regards,

Guido


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Russell Coker]

On Sat, 19 Mar 2011, "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
> My assumption is that most people don't care about all of the policy
> maintenance minutiae and don't want to be flooded with the patch emails.
>  But on the main list you can find out about the development direction
> and functionality changes; IMO thats why only ~3% of the subscribers
> constitute the majority of the list traffic.

Maybe we need a separate announcement mailing list for the 97%.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Guido Trentalancia]

On Sat, 19/03/2011 at 01.33 +1100, Russell Coker wrote:
> On Sat, 19 Mar 2011, James Carter <jwcart2@tycho.nsa.gov> wrote:
> > > NSA people:  How many subscribers are there to this list outside .gov?
> > >
> > > 
> > 
> > 887
> > 
> > There are 30 people who have posted 10 or more messages in the last
> > year.
> 
> On Sat, 19 Mar 2011, "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
> > > Tresys people:  How many subscribers to the refpolicy list are outside
> > > .gov?
> > 
> > 95

You see Russell, I wasn't too wrong on that (apologies again for
misspelling your first name). SELinux should not be considered. My
original message was posted on refpolicy and was only about policy
development ("this list").

> Any theories as to why are there almost 10* more people on the main list?
> 
> It seems to me that policy development is easier to get involved with than all 
> other types of SE Linux development, and it's more required.  One can do a lot 
> of SE Linux work without touching any of the C code, but it's not possible to 
> do much outside the distribution defaults without writing some policy.

I do not agree with you. MAC policy development requires knowledge of
the whole underlying OS including very silly details about location of
files (and including very silly details such as tiny differences in
different distributions). Developing SELinux userspace mostly requires
knowledge of libc, libselinux and friends (which have extensive
documentation as info and man pages as opposed to very short embedded
comments for interfaces in the .if files). Developing SELinux kernel is
probably something in between the two things when it comes to
difficulty, at least in my perception.

Writing C code is easier at least for me. And testing C code is easier
at least for me. For example the C compiler gives much more meaningful
warnings and messages. And you've got the debugger as well !

At the very least policy development is more tedious in my opinion.

But all of this is subject to personal attitudes and other similar
factors.

Regards,

Guido


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Russell Coker]

On Sat, 19 Mar 2011, Guido Trentalancia <guido@trentalancia.com> wrote:
> I do not agree with you. MAC policy development requires knowledge of
> the whole underlying OS including very silly details about location of
> files (and including very silly details such as tiny differences in
> different distributions).

Most of the policy is developed by people who don't have a good knowledge of 
other distributions.  They develop for the distribution they support and let 
other people support their own distributions.

Knowing how the entire OS works is necessary for the people who architect the 
policy, that is pretty much only Tresys and NSA employees at the moment.

Writing policy to suit an uncommon configuration of an application is usually 
a matter of just relabeling files and putting the output of audit2allow into a 
.te file, it's not particularly difficult.

> Developing SELinux userspace mostly requires
> knowledge of libc, libselinux and friends (which have extensive
> documentation as info and man pages as opposed to very short embedded
> comments for interfaces in the .if files). Developing SELinux kernel is
> probably something in between the two things when it comes to
> difficulty, at least in my perception.

Developing kernel code requires long build times and it's hard to debug (Linus 
has long been resistant to kernel debuggers).  Bugs in kernel code often crash 
the system which makes it difficult to diagnose them and may require some 
effort to get the system working again.

Developing library code isn't so simple either, a bug in libselinux or 
libsepol could make init fail which would also be more challenging than the 
usual debugging session.

A policy error that makes the system unbootable can be resolved by booting 
with enforcing=0 and then reading audit messages.

Also when doing user-space development you have to deal with the different 
programming styles of all the different applications and lots of shared object 
issues.  Debugging pam modules is one thing that's really not fun, setuid 
programs can't be ptraced and the pam interface isn't the easiest thing to 
work with.

> Writing C code is easier at least for me. And testing C code is easier
> at least for me. For example the C compiler gives much more meaningful
> warnings and messages. And you've got the debugger as well !

Nowadays most sysadmins aren't C coders.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Guido Trentalancia]

Hello Russell !

On Sat, 19/03/2011 at 10.52 +1100, Russell Coker wrote:
> On Sat, 19 Mar 2011, Guido Trentalancia <guido@trentalancia.com> wrote:
> > I do not agree with you. MAC policy development requires knowledge of
> > the whole underlying OS including very silly details about location of
> > files (and including very silly details such as tiny differences in
> > different distributions).
> 
> Most of the policy is developed by people who don't have a good knowledge of 
> other distributions.  They develop for the distribution they support and let 
> other people support their own distributions.
> 
> Knowing how the entire OS works is necessary for the people who architect the 
> policy, that is pretty much only Tresys and NSA employees at the moment.
> 
> Writing policy to suit an uncommon configuration of an application is usually 
> a matter of just relabeling files and putting the output of audit2allow into a 
> .te file, it's not particularly difficult.
> 
> > Developing SELinux userspace mostly requires
> > knowledge of libc, libselinux and friends (which have extensive
> > documentation as info and man pages as opposed to very short embedded
> > comments for interfaces in the .if files). Developing SELinux kernel is
> > probably something in between the two things when it comes to
> > difficulty, at least in my perception.
> 
> Developing kernel code requires long build times and it's hard to debug (Linus 
> has long been resistant to kernel debuggers).  Bugs in kernel code often crash 
> the system which makes it difficult to diagnose them and may require some 
> effort to get the system working again.
> 
> Developing library code isn't so simple either, a bug in libselinux or 
> libsepol could make init fail which would also be more challenging than the 
> usual debugging session.
> 
> A policy error that makes the system unbootable can be resolved by booting 
> with enforcing=0 and then reading audit messages.
> 
> Also when doing user-space development you have to deal with the different 
> programming styles of all the different applications and lots of shared object 
> issues.  Debugging pam modules is one thing that's really not fun, setuid 
> programs can't be ptraced and the pam interface isn't the easiest thing to 
> work with.
> 
> > Writing C code is easier at least for me. And testing C code is easier
> > at least for me. For example the C compiler gives much more meaningful
> > warnings and messages. And you've got the debugger as well !
> 
> Nowadays most sysadmins aren't C coders.

Meaningful thoughts, perhaps some of them would fit at the bottom of the
FAQ @selinuxproject.org as an intermediate level type of question ? It
gives an idea of the main difficulties that should be faced when
approaching development.

Regards,

Guido


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Linux use - was: Question: and the policy grows...

[Christopher J. PeBenito]

On 03/17/11 19:24, Russell Coker wrote:
> On Fri, 18 Mar 2011, Guido Trentalancia <guido@trentalancia.com> 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).
> 
> NSA people:  How many subscribers are there to this list outside .gov?
> 
> Tresys people:  How many subscribers to the refpolicy list are outside .gov?

95

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] Question: and the policy grows...

[Christopher J. PeBenito]

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
www.tresys.com | oss.tresys.com

[refpolicy] Question: and the policy grows...

[Guido Trentalancia]

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

[refpolicy] dual mailing list (was Question: and the policy grows...)

[Guido Trentalancia]

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] dual mailing list (was Question: and the policy grows...)

[Daniel J Walsh]

-----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-----

[refpolicy] dual mailing list (was Question: and the policy grows...)

[Guido Trentalancia]

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.