previously on this list Thorsten Glaser contributed: > > A wide misconception. Chroots are easily implemented and add security > > almost for free (often /dev/log is all that is needed) and so can be > > used by default without any potential problems, they also never bring > > new risks and always make life difficult for an attacker to raise > > priviledges or get what they are actually after when done > > correctly. Even at a simple level it should be obvious that they can > > just nullify the payload so the attacker simply goes elsewhere. Does > > Bwahahahahahahahahahahahahahahahahahaha! > > (To casual observers: the entire paragraph is very wrong.) > > Yes, chroots help isolating things, but, just like systrace(4), they > are far from being inescapable.
I also said the following and nothing is inescapable atleast in any general conversation, so who is being black and white now! Chroot provides a noticeable improvement in security at a very low cost in time to implement and almost 0 maintenance. Systrace has security merit too despite it's shortcomings at isolating ROOT in CERTAIN SITUATIONS and is used by sshd now by default. > > If the kernel > > can be attacked from the chroot then likely the MAC can and due to > > increased complexity, arguments just as easily arise against both. -- _______________________________________________________________________ '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) _______________________________________________________________________ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/80183.89090...@smtp103.mail.ir2.yahoo.com
