: patch set to update the git reference policy
PATCH 15/19 : patch set to update the git reference policy
policy/modules/system/selinuxutil.te +1 -0
@@ -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)
PATCH 15/19 : patch set to update the git reference policy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
policy/modules/system/selinuxutil.te files_read_etc_files(semanage_t) · line 447
Quoted 8 lines · 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
policy/modules/system/selinuxutil.te +1
-0@@ -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.
Quoted 9 lines
policy/modules/system/selinuxutil.te +0
-0mls_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-----
PATCH 15/19 : patch set to update the git reference policy
Quoted 12 lines · Dominick Grift
policy/modules/system/selinuxutil.te files_read_etc_files(semanage_t) · line 447
Quoted 8 lines · 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
policy/modules/system/selinuxutil.te +1
-0@@ -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_tdirectories. 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
PATCH 15/19 : patch set to update the git reference policy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 20 lines · Guido Trentalancia
Quoted 12 lines · Dominick Grift
policy/modules/system/selinuxutil.te files_read_etc_files(semanage_t) · line 447
Quoted 8 lines · 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
policy/modules/system/selinuxutil.te +1
-0@@ -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_tdirectories. 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)...
Quoted 5 lines
Of course it can be removed. So, in general
default_tshould 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 andetc_runtimefiles, why shouldn't it allowed to carry out operations ondefault_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.
Quoted 4 lines
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-----
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 15/19 : patch set to update the git reference policy
Quoted 50 lines · Christopher J. PeBenito
Quoted 31 lines · Dominick Grift
Quoted 20 lines · Guido Trentalancia
Quoted 12 lines · Dominick Grift
policy/modules/system/selinuxutil.te files_read_etc_files(semanage_t) · line 447
Quoted 8 lines · 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
policy/modules/system/selinuxutil.te +1
-0@@ -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_tdirectories. 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)...Quoted 5 lines
Of course it can be removed. So, in general
default_tshould 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 andetc_runtimefiles, why shouldn't it allowed to carry out operations ondefault_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 itdefault_t.Quoted 8 lines
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_tis not like other types likeusr_toretc_runtime_t. types likefile_t,default_t,unlabeled_tall 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 infile_contextsmatches this file, so it falls back todefault_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.
Quoted 5 lines
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 isfile_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