[buug] Various stuff from and related to yesterday's BUUG meeting

Michael Paoli Michael.Paoli at cal.berkeley.edu
Fri Mar 3 08:42:02 PST 2006


In not necessarily any particular order:

CoMPare and LiNk (cmpln) utility I wrote, details, code, etc.:
http://mail.pm.org/pipermail/oakland/2006-March/001795.html
http://www.rawbw.com/~mp/perl/

chroot(2) and "jails", etc.
<URL:news:1135281726.195196.127870 at o13g2000cwo.googlegroups.com>
>From BSD, also comes the "jail" facility, which includes use of
chroot(2), and other useful stuff to make such an environment secure and
perhaps also easier to set up and/or do so securely.  Some, but not
necessarily all, of these BSD "jail" capabilities/functionalties have
also been ported to other environments, e.g.:
http://www.jmcresearch.com/projects/jail/
and a quick check on Debian with apt-cache(8) search also reveals:
jailer - Builds and maintains chrooted environments
jailtool - Tool to build chroot-jails for daemons
With a bit of searching, e.g. via Google, there's lots of data out
there, ... of substantially varying quality, regarding chroot, etc.
Unfortunately a lot of the information is incomplete or only partially
correct, or in some cases rather to quite wrong.  Like some other
security areas - e.g. cryptography - many folks tend to think they know
it quite well, but don't really, ... but that doesn't stop them from
writing lots about it, thinking they do.  To do chroot(2) well, it's
probably best to carefully read and reference the relevant sections of
some good UNIX/LINUX(/BSD) security books that typically devote about a
chapter or so, to the topic.  From that, one should be able to
understand and put together a pretty good list of dos and don'ts
regarding securely constructing a chroot(2) environment.  (I haven't
done it recently enough to well recall such a list - and besides, these
things can sometimes change over time - e.g. when fundamental security
constructs, files, system calls, etc. change over time for various
UNIX/LINUX/BSD operating system versions/releases.)

fvwm(1), X11, etc.
Hmmmm, I still need to update stuff on my web pages so this stuff is
more findable, ... anyway, relevant URLs and such are mentioned here:
http://lists.balug.org/pipermail/balug-talk-balug.org/2005-November/003572.html
Note that it's very configurable, so, for example, one can change what
actions are available by various types of mouse events on window
elements (sides, corners, title bar and buttons provided by fvwm) ...
including potentially having no actions for those items and/or removing
most or all of them (e.g. just have a solid frame that does nothing and
no other window decorations).  Likewise with the function key
combinations and the like - one can redefine and/or take away any and/or
all of their fvwm functionality.  Similarly for mouse events on the root
window, those can be redefined and/or disabled too.  Of course lots of
fvwm information can also be found here:
http://www.fvwm.org/
fvwm isn't necessarily the only window manager that is so highly
configurable, but it is also a relatively light-weight window manager.
It's not nearly as bloated or resource intensive as the typical Gnome or
KDE X11 environment.
With LINUX, one can also add/remove/enable/disable virtual consoles, so,
for example, if one wanted, one could configure the system to have
precisely and only one virtual console.  If one wants/needs to disable
<CTRL><ALT><BACKSPACE> and similar functionality from xfree86 or other X
servers, there are probably possible ways to do that (e.g. change the
code, or perhaps possibly remap certain keys or key combinations).

UNIX/LINUX/BSD/... passwords and their hash algorithms and security,
etc.
the end of crypt() passwords ... please?:
http://www.usenix.org/publications/login/2003-12/pdfs/perrine.pdf
password protection for modern operating systems:
http://www.usenix.org/publications/login/2004-06/pdfs/alexander.pdf
The above I think I mentioned, and may have also posted about some while
back.  As a public service, USENIX makes their ;login: issues more than
one year old available to the public (newer editions are available only
to members).  Anyway, the two ;login: articles above were the ones I had
in mind regarding password hash types used and their relative
strengths/algorithms, and precomputation of many, most, or all possible
crypt(3) password hashes - along with at least one corresponding
cleartext password for each.



More information about the buug mailing list