On Thursday 30 August 2007 19:29, Pádraig Brady <P@xxxxxxxxxxxxxx> wrote: > The organising of programs between coreutils, util-linux-ng and > bsdmainutils got me thinking about runcon. > > Isn't runcon linux specific, and hence should be part of util-linux-ng > rather than coreutils? http://etbe.coker.com.au/2007/08/31/is-se-linux-only-for-linux/ I've written a blog post on this topic. It will go live in 10 hours. Below is the content and above is the permalink. In summary, no I don't think it's inherently Linux specific and I think that it should remain part of coreutils. I have just been asked for advice on whether SE Linux is Linux specific, and therefore whether code related to SE Linux should always be stored with other Linux specific code instead of being in the main branch of certain free software projects. One example of SE Linux access controls being implemented on a different OS is the work to port SE Linux to Mac OS/X (<A HREF="http://selinux-symposium.org/2007/papers/01-SEDarwin.pdf";>here is a paper on the topic presented at the SE Linux Symposium 2007</A>). One thing I have been doing is trying to get some friends interested in doing similar work for <A HREF="http://www.gnu.org/software/hurd/hurd.html";>GNU Hurd</A> (there are some similarities between Darwin and HURD so the work done on Mac OS/X "Darwin" will help the HURD effort). I believe that The HURD has the potential to offer significant security benefits due to the micro-kernel design. One significant problem area in computer security is kernel security flaws, if the kernel can be split into a set of independent processes that run with minimal privileges then the scope of such problems is dramatically decreased - and the possibility of upgrading parts of a kernel on a live machine is provided. As people such as Linus point out there is a performance overhead to micro-kernels, but most machines are idle most of the time anyway. I believe that reliability and security are more important than getting the last 10% of system performance for most machines. The success of Xen is evidence that features other than maximum performance are desired. Another example of SE Linux access controls on a non-Linux platform is <A HREF="http://www.trustedbsd.org/mac.html";>the MAC framework in the TrustedBSD project</A>. This implements SE Linux access controls on top of FreeBSD. >From reading the documentation it seems that the amount of changes required to the SE Linux code base for implementation on TrustedBSD was significantly smaller than the changes required for Darwin. So it seems that a significant portion of the SE Linux code base is portable, and in particular the user-space code should port well. The interfaces for and methods labelling files etc should port well between platforms. Therefore I recommend not having SE Linux code split into Linux specific trees and instead having a compile option to enable SE Linux support. -- russell@xxxxxxxxxxxx http://etbe.coker.com.au/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development - To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
