Re: goals for hardening Debian: ideas and help wanted
previously on this list Tzafrir Cohen contributed:
> > A wide misconception. Chroots are easily implemented and add security
> > almost for free
>
> Not completely for free. You now have an extra mini-system to maintain.
>
> (often /dev/log is all that is needed) and so can be
You completely misunderstand. Many daemons have chroot config options
for security reasons. I am asking does Debian use them by default and
if not why not.
> > used by default without any potential problems,
>
> > they also never bring
> > new risks
>
> unless you forget to unpdate them.
>
You don't need to update them, they are basically empty and created on
daemon startup with perhaos one or two files like a dns root key for
unbound which is then self maintained (better if writes could be
avoided though). I am talking about dropping an unpriviledged process
permissions to next to nothing running with no shell and no filesystem
access so that any exploit in the network/any input code is far
less likely to get any further.
> It's also worth mentioning systemd-nspawn:
> http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
Not at all, it hasn't been tested for this, isn't supported by daemons
that crucially use "priviledge seperation, which involves forking
children so a tiny process doing what root needs or a tiny process doing
the dangerous stuff in a chroot as an unpriviledged user or a
combination of both and any wrong communication means the priv parent
dies), sounds like it does what most Linux admins think chroot is only
good for and talks about all sorts of stuff that would make any chroot
in this way pointless. "more powerful" I expect means less secure in
this usage.
p.s. this is proper security in quality daemons implementing application
specific security not polkit/systemd rubbish. Whilst you have got me to
mention systemd I shall bring something up that has yanked my chain.
I suppose the debian page
https://wiki.debian.org/Debate/initsystem/systemd
Is just written by random developers and is not official or speaking as
a debian collective because it is very unbalanced indeed.
Embedded more performance less memory blah blah well that depends as
systemd is NOT compatible with application specific embedded that
basically is what embedded is all about and the Linux kernel is
atleast for now and would be forked otherwise. I could argue further
about larger systems but I won't bother, it would just be twisted and
move away from the main point anyway.
http://lists.busybox.net/pipermail/buildroot/2011-November/047612.html
--
_______________________________________________________________________
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'
(Doug McIlroy)
In Other Words - Don't design like polkit or systemd
_______________________________________________________________________
I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
_______________________________________________________________________
Reply to: