On Thursday 01 January 2009 13:55, Frans Pop <elen...@planet.nl> wrote: > > They were, I have just made some significant changes. > > Thanks a lot for that. BTW, wouldn't it make sense to have separate wiki > pages with setup info per release? The instructions for Etch probably are > still valid.
It would. In preparation for that I made my personal web page about it include Lenny in the name. Of course Etch SE Linux isn't particularly functional without a set of extra packages that are only on my personal web site. I have been considering removing those packages due to an apparent lack of interest. > I'll be happy to work with you on designing some alternative way to > (optionally) install *and* activate SELinux during new installations. > Main restriction there will be that policy forbids us to modify config > files of other packages, so any activation of SELinux in packages such as > the changes in PAM config files will need to be supported by the relevant > packages, probably through debconf settings. Currently in Debian booting the kernel with "selinux=1" is needed to enable SE Linux. This is in contrast to RHEL, CentOS, and Fedora where it's enabled by default and booting with "selinux=0" is required if you want to disable it. So if the user typed "install selinux=1" from the installer then the install kernel would have SE Linux enabled, and querying /proc/cmdline for selinux=1 could be used for later stages of installation to determine whether SE Linux was desired. Anaconda (the Red Hat installer) looks for selinux=0 to change it's installation options. Then if SE Linux was enabled we could load the policy at a suitable time during the installation process and have all the files correctly labelled at the first boot. The Debian SE Linux policy is highly modular (as opposed to every Red Hat release I've tried which only uses the module support for end-user modifications) and modules are automatically selected to match the packages you have installed. This results in less kernel memory being used, but means that we need to install the modules before installing packages (as opposed to the alternatives which are all ugly). Can we have an extension to APT to make it call a script before it installs a set of packages? NB It doesn't really matter if the sysadmin decides to abort the installation. Having a few unused policy modules doesn't do any harm, it's only when you have a couple of hundred of them that you start wasting kernel memory. > From the few tests I've done SELinux has matured a lot and the Debian > packaging has improved tremendously, mainly through your efforts. Thanks! Also Manoj has been doing some great work recently and we are building on a heap of work from all the other DDs who have worked on this and the code from the NSA, Tresys, Red Hat, and others. > There > are a lot less issues after activation then there were for Etch. I hope > that trend will continue, but especially that users will be able to get > more support. Yes, I have a number of exciting things planned for this year. One of which requires getting bittorrent in Lenny working to serve my torrents - any advice from a bittorrent expert would be appreciated off-list. NB I have not filed a bug report against bittorrent as I'm not sure whether it's a bug or whether I just stuffed up. > However, I also don't yet see SELinux becoming a standard service on all > Debian systems. It's just too complex a framework for that. "Yet" being the relevant word. I've been working on this for more than 7 years and it just keeps getting better. In time I think that I will get you and the other members of the Debian Installer team to agree with me. NB I would be happy with a single question being asked of the user "Do you want SE Linux?" with "yes" and "no" being menu options. I don't plan to push for SE Linux to be made the default for the Debian install in the same way as it is for Fedora and RHEL (but I would be happy if it happened). > Cheers and happy new year, Thanks, same to you! -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
