On Wed, 2010-01-27 at 23:47 +0100, Guido Trentalancia wrote: > Hello Stephen ! > > On Tue, 2010-01-26 at 12:52 -0500, Stephen Smalley wrote: > >> Alternatively to spending time on documenting the current limitation, it > >> might be more interesting to try removing the restriction from the > >> SELinux kernel code and investigating what needs to be done within the > >> kernel to enable it to be done safely. Primarily this would mean: > >> - pushing the selinux_mls_enabled flag inside the policydb so that it > >> could be per-policydb (this is already the case in libsepol), > >> - in the non-MLS to MLS case, ensuring that the MLS fields of the > >> context for all existing entries in the sidtab are filled in with a > >> suitable default value, likely taken from one of the initial SIDs, > >> - in the MLS to non-MLS case, freeing any storage used by the MLS fields > >> in the context for all existing entries in the sidtab. > > > FYI, both of the latter two items would be handled inside > > of ss/services.c:convert_context(). > > First of all, I am sorry for the late reply. > > The idea seems very attractive: allowing the transition between MLS/MCS and non-MLS/non-MCS policies (and viceversa) at the kernel level can be considered a new feature and it is certainly better than writing piece of documentation about current limitation of the code. > > I am not very familiar with the kernel code, but before discussing it further, I have noticed that the code at lines 1740-1744 of policydb.c (in the latest released kernel, within policydb_read()) never gets executed, even though the switch from MLS/MCS to standard policy does not take place. It's a minor issue, but it's probably worth of consideration because there must be some wrong assumption in the if statements there. Similarly I don't understand why at line 1730 selinux_mls_enabled is set to 1, even though we don't have a MLS/MCS policy loaded and we are not switching to a MLS/MCS policy either... > > And at the moment I am also not able to get lines 1725-1729 executed, by trying to switch from a non-MLS/MCS policy to a MLS/MCS policy. > > To do the switch I am just using "make load" in the two respective policies that I have compiled (and installed in different stores) beforehand. I believe "make load" just executes semodule (without "-n"). > > What do you say ? I must admit, when a few days ago I was trying to install the MCS policy with the same name of the currently loaded standard policy, lines 1725-1729 were getting executed and I use to get the error message from the kernel... > > Have you had any other idea about a possible implementation of this new feature ? I will try to look at the kernel code more closely... First, if you are going to do SELinux kernel development, then develop patches against the #next branch of the security-testing-2.6 tree. See: http://selinuxproject.org/page/Developers#Kernel_developers http://security.wiki.kernel.org/index.php/Kernel_Repository To exercise the restriction on MLS->non-MLS or vice versa, build and install two policies on your system under different names, one MLS or MCS and one standard. Boot with /etc/selinux/config pointing to one of the policies, and then switch /etc/selinux/config to point to the other and attempt to run load_policy. That should fail with the error message logged to /var/log/messages and your dmesg output. Then reboot with the new policy, and switch /etc/selinux/config to point to the other policy and try running load_policy again. This should also fail similarly. That should exercise both cases. The condition: ((le32_to_cpu(buf[1]) & POLICYDB_CONFIG_MLS)) tests whether or not the policy being loaded was built with MLS enabled. The condition: (ss_initialized && !selinux_mls_enabled) tests whether policy has ever been loaded (ss_initialized) and if so, whether it was previously MLS-disabled. The condition: (ss_initialized && selinux_mls_enabled) tests whether policy has ever been loaded (ss_initialized) and if so, whether it was previously MLS-enabled. Note that we "goto bad" in the error paths and thus never reach setting of selinux_mls_enabled to 1 in the error case. To support switching, we must change selinux_mls_enabled from a global flag to one that is part of the policydb state, so that we can have a currently active policydb that has one value of MLS enabled and a policydb that is being loaded that has a different value (up to the point where we switch from the old to the new). That will be the most painful part of the patch - you'll have to track down all uses of selinux_mls_enabled and replace them with e.g. policydb.mls_enabled (when referencing the active policydb) or p->mls_enabled (when referencing a particular policydb, like the one that is being loaded). Then you need convert_context() to correctly deal with the MLS fields of the context when switching, and then you can finally safely remove the restriction from policydb_read(). -- Stephen Smalley 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
