On Fri, 2008-03-28 at 10:32 -0400, James Carter wrote: > On Fri, 2008-03-28 at 09:51 -0400, Stephen Smalley wrote: > > On Fri, 2008-03-28 at 09:36 -0400, James Carter wrote: > > > On Fri, 2008-03-28 at 08:59 -0400, Stephen Smalley wrote: > > > > On Fri, 2008-03-28 at 08:56 -0400, Joshua Brindle wrote: > > > > > Stephen Smalley wrote: > > > > > > On Fri, 2008-03-28 at 11:06 +1100, Russell Coker wrote: > > > > > > > > > > > >> http://etbe.coker.com.au/2008/03/28/debian-se-linux-status/ > > > > > >> > > > > > >> Those of you who don't read Planet SE Linux but who are interested in Debian > > > > > >> may want to read the above. > > > > > >> > > > > > > > > > > > > Regarding the mismatch in policy version between your domU vs. dom0, you > > > > > > should be able to build older policy versions via the config setting > > > > > > in /etc/selinux/semanage.conf (modular build) or via the OUTPUT_POLICY= > > > > > > setting in build.conf, overridable on the make command line (monolithic > > > > > > build). > > > > > > > > > > > > Or you could install newer selinux core userland in your dom0 such that > > > > > > it can read and downgrade the latest policy to the one supported by your > > > > > > kernel (libselinux policy load logic will convert a newer policy to an > > > > > > older one at load time for you). > > > > > > > > > > > > Agree that converting between non-MLS and MLS/MCS is very painful at > > > > > > present. Part of that we can fix (inappropriate dependencies in > > > > > > semanage/seobject.py that should be querying the policy store via > > > > > > libsemanage/libsepol rather than checking the running policy), and part > > > > > > we cannot (still won't be able to switch the kind of policy at policy > > > > > > reload in the kernel). I'd actually prefer that we just always enable > > > > > > the MLS engine and field for simplification, presenting the same > > > > > > experience to all users, and ensuring that we are all testing the same > > > > > > code paths. > > > > > > I thought that MLS just added additional code paths. Are there code > > > paths that are only taken for non-MLS policies? > > > > > > > I don't know how others feel about that though - I know > > > > > > that Gentoo has historically not enabled MCS/MLS, and that upstream > > > > > > refpolicy still defaults to not enabling it (standard). > > > > > > > > > > > > I'm not sure why MLS support significantly increases policy build time > > > > > > though. > > > > > > > > > > > > Isn't that an argument for keeping non-MLS support? ;) > > > > I don't believe that it actually does significantly increase policy > > build time (or if it does, that would be a bug). Possibly Russell just > > means that building both MLS and non-MLS takes longer, or that the mls > > modules.conf includes more modules, or something along those lines? > > > > > What is the difference in overhead between an MLS and a non-MLS system? > > > Would there be a noticeable difference in resources used by a non-MLS > > > system and one that had a single level of s0 and no categories? (Can > > > you actually define only one level and no categories?) > > > > If you don't define any actual MLS constraints in policy, then it > > shouldn't impose any real runtime overhead (and even when you do, that's > > all masked by the AVC, of course). Yes, you should be able to define > > just one level and no categories, although I doubt that defining > > categories significantly expands the policy (just because they are > > defined doesn't mean you have to use them in contexts). > > You can't. > > m4 -D enable_mls -D distro_redhat -D mls_num_sens=1 -D mls_num_cats=0 -D > mcs_num_cats=256 -D hide_broken_symptoms -D self_contained_policy > policy/flask/security_classes policy/flask/initial_sids > policy/flask/access_vectors policy/support/file_patterns.spt > policy/support/ipc_patterns.spt policy/support/loadable_module.spt > policy/support/misc_macros.spt policy/support/misc_patterns.spt > policy/support/mls_mcs_macros.spt policy/support/obj_perm_sets.spt > policy/mls policy/mcs > tmp/pre_te_files.conf > m4: memory exhausted > make: *** [tmp/pre_te_files.conf] Error 1 Ok - I only glanced at the checkpolicy grammar, which allows no categories to be defined. But I suppose that refpolicy build infrastructure and likely even the libsepol and kernel code will be unhappy with zero categories presently. > But I see your point. There isn't going to be any appreciable overhead > in defining additional levels and categories that aren't used. And > there is really no gain in running a non-MLS system as compared to an > MLS system that is running everything at the same level and which > doesn't have any MLS constraints. Yes, that's the point. > > > > With the mainstreaming of the MLS support and turning it from a > > compile-time option into a runtime load option, there isn't any real > > difference in the in-core context structures even when you have MLS > > disabled. So you aren't saving anything there. > > > > > > > Also note that the default (and only) policy on Ubuntu is non-mls. > > > > > > > > Why? > > > > > > > > I think we set ourselves up for application and user confusion and > > > > incompatibility by having different context formats in the different > > > > distributions that support SELinux. And it definitely creates a > > > > maintenance burden - having to test both cases always. Which apparently > > > > we aren't doing a good job of, as semanage user -a will presently always > > > > fail on a non-MCS/MLS system. > > > > > > > > > > I don't think that we should address deficiencies in the tool-chain by > > > reducing flexibility. > > > > No - it isn't just deficiencies in the tool chain. It increases our > > maintenance burden to have multiple options and code paths to exercise, > > and it is user- and application visible since it affects the context > > format. > > > > What about the differences between monolithic policy and modular policy? > Isn't that a maintenance burden as well? A monolithic policy can't be > managed with semange, so that is a user visible difference as well. That was a technology transition for SELinux, one that all the distributions went through. All the distributions now use modular, managed policy by default, and monolithic policy support remains for legacy systems (e.g. RHEL4) and possibly for embedded systems since modular, managed policy presently has a real cost to it (unlike the MLS support). Similarly, MLS has gone from a compile-time only, universally disabled option to a load-time, enabled-by-default option in the majority of SELinux systems today. So possibly the maintenance burden argument doesn't hold up, since we'd need to retain such support anyway for legacy systems - although we could at least deprecate it and eventually drop it from the trunk, leaving it only in some legacy stable branch. But the common user experience argument seems valid to me. -- 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.
