[refpolicy] [PATCH/RFC 15/19]: patch set to update the git reference policy

[refpolicy] [PATCH/RFC 15/19]: patch set to update the git reference policy

[Guido Trentalancia]

diff -pruN -x .git -x booleans.conf -x corenetwork.if -x corenetwork.te -x modules.conf refpolicy-git-18012011/policy/modules/system/selinuxutil.te refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te
--- refpolicy-git-18012011/policy/modules/system/selinuxutil.te	2011-01-17 19:36:10.814131755 +0100
+++ refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te	2011-01-23 04:14:02.662963912 +0100
@@ -444,6 +444,7 @@ files_read_etc_files(semanage_t)
 files_read_etc_runtime_files(semanage_t)
 files_read_usr_files(semanage_t)
 files_list_pids(semanage_t)
+files_search_default(semanage_t)
 
 mls_file_write_all_levels(semanage_t)
 mls_file_read_all_levels(semanage_t)

[refpolicy] [PATCH/RFC 15/19]: patch set to update the git reference policy

[Dominick Grift]

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

On 01/24/2011 01:44 AM, Guido Trentalancia wrote:
> diff -pruN -x .git -x booleans.conf -x corenetwork.if -x corenetwork.te -x modules.conf refpolicy-git-18012011/policy/modules/system/selinuxutil.te refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te
> --- refpolicy-git-18012011/policy/modules/system/selinuxutil.te	2011-01-17 19:36:10.814131755 +0100
> +++ refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te	2011-01-23 04:14:02.662963912 +0100
> @@ -444,6 +444,7 @@ files_read_etc_files(semanage_t)
>  files_read_etc_runtime_files(semanage_t)
>  files_read_usr_files(semanage_t)
>  files_list_pids(semanage_t)
> +files_search_default(semanage_t)

There should not be any default_t directories. Thus this shouldnt be
allowed.

>  
>  mls_file_write_all_levels(semanage_t)
>  mls_file_read_all_levels(semanage_t)
> 
> 
> _______________________________________________
> 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/

iEYEARECAAYFAk09hUUACgkQMlxVo39jgT8WGwCgt/ii7cqY1g1vuFIvYo5Fb1/b
L1UAnRASSyiTspd/9MOQp9fT4gdL3Ff9
=PIvv
-----END PGP SIGNATURE-----

[refpolicy] [PATCH/RFC 15/19]: patch set to update the git reference policy

[Guido Trentalancia]

On Mon, 24/01/2011 at 14.57 +0100, Dominick Grift wrote:
> On 01/24/2011 01:44 AM, Guido Trentalancia wrote:
> > diff -pruN -x .git -x booleans.conf -x corenetwork.if -x corenetwork.te -x modules.conf refpolicy-git-18012011/policy/modules/system/selinuxutil.te refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te
> > --- refpolicy-git-18012011/policy/modules/system/selinuxutil.te	2011-01-17 19:36:10.814131755 +0100
> > +++ refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te	2011-01-23 04:14:02.662963912 +0100
> > @@ -444,6 +444,7 @@ files_read_etc_files(semanage_t)
> >  files_read_etc_runtime_files(semanage_t)
> >  files_read_usr_files(semanage_t)
> >  files_list_pids(semanage_t)
> > +files_search_default(semanage_t)
> 
> There should not be any default_t directories. Thus this shouldnt be
> allowed.

This stems from the fact that at some point I came to a state where
while working from the terminal (as opposed to working from a graphical
terminal), semanage had trouble dealing with some temporary local
modules that I was working with for testing purposes (they were labelled
default_t)...

Of course it can be removed. So, in general default_t should never
appear anywhere in the policy ? Just for curiosity, what is the reason
behind that ? If it is allowed to carry out operations on usr and
etc_runtime files, why shouldn't it allowed to carry out operations on
default_t ?

Regards,

Guido

[refpolicy] [PATCH/RFC 15/19]: patch set to update the git reference policy

[Dominick Grift]

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

On 01/24/2011 09:54 PM, Guido Trentalancia wrote:
> On Mon, 24/01/2011 at 14.57 +0100, Dominick Grift wrote:
>> On 01/24/2011 01:44 AM, Guido Trentalancia wrote:
>>> diff -pruN -x .git -x booleans.conf -x corenetwork.if -x corenetwork.te -x modules.conf refpolicy-git-18012011/policy/modules/system/selinuxutil.te refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te
>>> --- refpolicy-git-18012011/policy/modules/system/selinuxutil.te	2011-01-17 19:36:10.814131755 +0100
>>> +++ refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te	2011-01-23 04:14:02.662963912 +0100
>>> @@ -444,6 +444,7 @@ files_read_etc_files(semanage_t)
>>>  files_read_etc_runtime_files(semanage_t)
>>>  files_read_usr_files(semanage_t)
>>>  files_list_pids(semanage_t)
>>> +files_search_default(semanage_t)
>>
>> There should not be any default_t directories. Thus this shouldnt be
>> allowed.
> 
> This stems from the fact that at some point I came to a state where
> while working from the terminal (as opposed to working from a graphical
> terminal), semanage had trouble dealing with some temporary local
> modules that I was working with for testing purposes (they were labelled
> default_t)...
> 
> Of course it can be removed. So, in general default_t should never
> appear anywhere in the policy ? Just for curiosity, what is the reason
> behind that ? If it is allowed to carry out operations on usr and
> etc_runtime files, why shouldn't it allowed to carry out operations on
> default_t ?

locations unknown to selinux are labelled default_t. So for example if
you create a dir named /test in the root of the filesystem. There is no
file context specification for it and thus selinux labels it default_t.

Basically it signals some incompatibility in that sense because files
always need a label, and this should not happen.

Why should refpolicy support a scenario that should never happen in the
first place? default_t is not like other types like usr_t or
etc_runtime_t. types like file_t, default_t, unlabeled_t all signal some
other issues. I think this is discussed in "Fedora SELinux user guide"
(you can find it with google, its a free document.

> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk096I4ACgkQMlxVo39jgT9q3wCcCIsGquSkb+NWEdXA3Dn1FCEc
xMYAn0PcLCUxsHvl4olv4Su7/qXlkjL0
=xdPO
-----END PGP SIGNATURE-----

[refpolicy] [PATCH/RFC 15/19]: patch set to update the git reference policy

[Guido Trentalancia]

On Mon, 31/01/2011 at 14.38 -0500, Christopher J. PeBenito wrote:
> On 1/24/2011 4:01 PM, Dominick Grift wrote:
> > On 01/24/2011 09:54 PM, Guido Trentalancia wrote:
> >> On Mon, 24/01/2011 at 14.57 +0100, Dominick Grift wrote:
> >>> On 01/24/2011 01:44 AM, Guido Trentalancia wrote:
> >>>> diff -pruN -x .git -x booleans.conf -x corenetwork.if -x corenetwork.te -x modules.conf refpolicy-git-18012011/policy/modules/system/selinuxutil.te refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te
> >>>> --- refpolicy-git-18012011/policy/modules/system/selinuxutil.te	2011-01-17 19:36:10.814131755 +0100
> >>>> +++ refpolicy-git-18012011-new/policy/modules/system/selinuxutil.te	2011-01-23 04:14:02.662963912 +0100
> >>>> @@ -444,6 +444,7 @@ files_read_etc_files(semanage_t)
> >>>>   files_read_etc_runtime_files(semanage_t)
> >>>>   files_read_usr_files(semanage_t)
> >>>>   files_list_pids(semanage_t)
> >>>> +files_search_default(semanage_t)
> >>>
> >>> There should not be any default_t directories. Thus this shouldnt be
> >>> allowed.
> >>
> >> This stems from the fact that at some point I came to a state where
> >> while working from the terminal (as opposed to working from a graphical
> >> terminal), semanage had trouble dealing with some temporary local
> >> modules that I was working with for testing purposes (they were labelled
> >> default_t)...
> >>
> >> Of course it can be removed. So, in general default_t should never
> >> appear anywhere in the policy ? Just for curiosity, what is the reason
> >> behind that ? If it is allowed to carry out operations on usr and
> >> etc_runtime files, why shouldn't it allowed to carry out operations on
> >> default_t ?
> >
> > locations unknown to selinux are labelled default_t. So for example if
> > you create a dir named /test in the root of the filesystem. There is no
> > file context specification for it and thus selinux labels it default_t.
> >
> > Basically it signals some incompatibility in that sense because files
> > always need a label, and this should not happen.
> >
> > Why should refpolicy support a scenario that should never happen in the
> > first place? default_t is not like other types like usr_t or
> > etc_runtime_t. types like file_t, default_t, unlabeled_t all signal some
> > other issues. I think this is discussed in "Fedora SELinux user guide"
> > (you can find it with google, its a free document.
> 
> This is the right idea, but I want to clarify the labeling.
> 
> default_t: this means no entry in file_contexts matches this file, so it 
> falls back to default_t.
> 
> unlabeled_t: this means the object has an invalid context.  Typically 
> this happens if a type is removed from the policy while the system is 
> running.
> 
> file_t: this means a filesystem that supports extended attributes is 
> mounted for the first time on a SELinux system.  The default for the 
> files in this case is file_t.
> 
> In all of these cases, the security attributes of the object are unknown.

Yes. I knew already about unlabeled_t and default_t, but I didn't know
about the existence and meaning of file_t, as I thought it was going to
default to unlabeled_t in the case mentioned above.

So good to know (we never stop learning) and thanks for pointing that
out, Christopher !

Basically, what happened is that I had a local problem with semanage
configuration, that led to a mislabeled /root directory. Everything
sorted out now.

Regards,

Guido