Debian / SE-Linux
hi there,
i've been playing with selinux and it is a great idea and also
a massive shift and therefore a royal pain at the same time.
strategically, it is necessary.
if linux becomes more popular than windows, which is only going
to be a matter of time, then we're going to see viruses and more
attacks against machines. it's already possible to compromise
a box via one service - and that simply shouldn't be possible.
therefore selinux is necessary as it restricts the actions a
program can take. GREAT!
the issue is, therefore, how to make the transition easier, rather
than fighting it (and if you don't agree that it is necessary
for selinux to be adopted mainstream into linux, please say so,
and why, and also you do not need to read any further).
for example, people are at present being asked to compile their
own kernels because if you compile it with SElinux and then not
use it, you get an approximate 2% performance penalty.
for example, an entire set of base utilities - pam, bsdutils,
login and coreutils to name a few - are having to be patched,
compiled, and made available SEPARATELY by one or two
individuals... and then of course their .debs become very
rapidly out-of-date.
then there's policy files, which are maintained *separately*
from the packages they are responsible for.
if someone recommended a change to debian policy on dpkg
package maintenance that all unix permissions - all usage
of chmod, chown, adduser, addgroup etc. be moved _out_ of
the /var/lib/dpkg/info/*.[pre/post][inst/rm] and config files,
and moved _into_ a separate package called "unix-policy",
and that one maintainer be responsible for it,
they'd be laughed off the lists.
... but nobody blinks an eye when a package called "selinux-policy"
is created and maintained by pretty much only one or two individuals.
so, these are the issues in order to get selinux to work:
1) the kernel must be compiled (automatically a stack-load of
potentially interested people switch off)
2) you must DOWNGRADE certain critical packages (which are now
out-of-date)
3) you take pot-luck as to whether the policy files are up-to-date
or whether the policy file maintainers have managed to create
a policy for your package _at all_.
and the documentation on selinux policy editing is... extremely
harsh, and could do with a few more people understanding it.
therefore, i urge people to discuss and debate the following:
1) serious consideration be given to compiling SElinux by default
IN, the default development option for selinux enabled to be
switched to OFF (the reverse of its present setting), and requiring
the kernel init option "selinux=on" in order for it to be enabled.
alternatively, could someone brave enough ask herbert if he could
do a kernel-image-2.6.x-selinux-386? :)
2) the modifications and patches to wdm, login, pam and other
packages (e.g. see http://selinux.lemuria.org/newselinux/ and
then go into each subdirectory to find the *.diff patches) be
submitted to the maintainers of these packages, and they be
double-checked against NON selinux kernel and be adapted dynamically
detect whether they are running against an selinux or non-selinux
kernel.
3) this is the biggie: serious consideration be given to updating
debian policy to ensure that each debian maintainer be responsible
for the corresponding domain/program/PACKAGENAME.te,
file_contexts/program/PACKAGENAME.fc, net_contexts (if the program
requires network access) and any other policy files.
notes and things to think about:
- gentoo and redhat (fedora) have adopted selinux by default:
when's debian going to?
- one person - russell coker - cannot be left with the sole
responsibility for creating and maintaining selinux policy files.
he is the single point of failure and also cannot be expected to
keep up with debian unstable package turnover.
re 3):
- it looks like a net_contexts.d would be required for package
convenience, if such a route were to be adopted.
- on the basis that any package maintainer is expected to understand
traditional unix security, surely they should also be expected to
understand selinux policy as well.
the advantage will be that (for example in the case of wdm) they will
go "hmmm, that's bad. _surely_ wdm doesn't need write access to
/etc??? oh bugger, yes it does because it demands write access to
/etc/X11/wdm, ah that's bad, better fix it" and will find and report
some of the security problems.
food for thought?
l.
--
--
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<a href="http://lkcl.net";> lkcl.net </a> <br />
<a href="mailto:lkcl@lkcl.net";> lkcl@lkcl.net </a> <br />
Reply to: