| Solar_Diz |
i will, however,
refer to the slides we used at NordU2002 |
| Solar_Diz |
http://www.openwall.com/presentations/nordu2002-owl-html+images/ |
| Solar_Diz |
please get
equipped with either a web browser or a local copy of the slides (just
half a meg gzipped) |
| Solar_Diz |
there's also
a "victim" Owl box you could play with |
| Solar_Diz |
(the DNS record
will go away once we're done) |
| Solar_Diz |
ssh uninet.tmp.openwall.com |
| Solar_Diz |
l: uninet |
| Solar_Diz |
p: franc&gather.school |
| Solar_Diz |
(i won't spend
too much time tracking any abuse, so please be polite there) |
| Solar_Diz |
ok, so let's
get started with the real stuff |
| Solar_Diz |
(slide 2) |
| Solar_Diz |
the first
question i'd expect from anyone who hears of another Linux distribution
is, -- |
| Solar_Diz |
"why are you
doing that? aren't there enough?" |
| Solar_Diz |
well, this
time the answer is we aren't satisfied with the approach to security (as
well as certain other things) found in other distributions |
| Solar_Diz |
i'll explain |
| Solar_Diz |
the problems
with other major distributions of Linux: |
| Solar_Diz |
(as we see
them) |
| Solar_Diz |
1. most care
to patch known security vulnerabilities which are "bad enough", yet do
little to prevent vulnerable software from getting into the distribution
in the first place |
| Solar_Diz |
there're several
reasons why this is the case |
| Solar_Diz |
one reason
is they simply don't value security so much |
| Solar_Diz |
another reason
is it's different parts of the team/company who package new software and
who are responsible for security |
| Solar_Diz |
2. There're
usually more than just a few pieces of software in a distribution which
provide a certain bit of functionality, thereby unnecessarily increasing
the risk |
| Solar_Diz |
(for those
joining the channel, questions and comments on #qc please, not privately
to me) |
| Solar_Diz |
as a result,
the number of vulnerabilities affecting each major distribution that hit
Bugtraq is high, and those are only the ones which are "bad enough" |
| Solar_Diz |
(by "bad enough"
in the context of major distributions i mean those which would trigger
advisories from the vendor) |
| Solar_Diz |
(for example,
timing leaks which allow for inferring valid usernames, a topic currently
on Bugtraq, would hardly cause those vendors to even look into patching
the code) |
| Solar_Diz |
(slide 3) |
| Solar_Diz |
(for those
joining, http://www.openwall.com/presentations/nordu2002-owl-html+images/) |
| Solar_Diz |
another part
of the question "why do this" is, -- isn't there already a secure Linux
distribution? |
| Solar_Diz |
really, the
idea to make one appeared no later than 1998 at which time there were several
projects started and mailing lists created |
| Solar_Diz |
(most such
projects died before being started) |
| Solar_Diz |
however, several
other secure Linux distro projects do exist |
| Solar_Diz |
in fact, i
maintain an open directory (http://dmoz.org)
category for those |
| Solar_Diz |
unfortunately,
i see several fundamental problems with those: |
| Solar_Diz |
1. most choose
software based on security track record |
| Solar_Diz |
basically,
if program X hasn't been mentioned on Bugtraq, it probably is secure and
we may package it safely |
| Solar_Diz |
indeed this
is a wrong attitude |
| Solar_Diz |
a good security
track record is no replacement for source code review; unless the software
component is very popular, the track record hardly says anything on its
design or code quality |
| Solar_Diz |
one example
is xinetd. it was believed to be "secure" by many, until it got packaged
into several distributions (primarily Red Hat Linux 7+) and vulnerabilities
started falling |
| Solar_Diz |
(yes, we package
xinetd, too, although we did take certain steps to reduce the risks and
didn't have the expectation of it being so safe) |
| Solar_Diz |
then, it isn't
just the choice of software which matters |
| Solar_Diz |
once you choose
a piece of software, there may well be more work to be done on integrating
it cleanly and applying privilege separation within the OS (more on that
later) |
| Solar_Diz |
2. there's
often an emphasis on kernel modifications |
| Solar_Diz |
while i am
guilty of doing some of those myself, i don't believe in them religiously
like i know some people do ;-) |
| Solar_Diz |
another unfortunate
property of those is that their code quality (and sometimes concepts) is
often inadequate |
| Solar_Diz |
kernel modifications
are also generally not something which would justify an entire distribution
project |
| Solar_Diz |
they usually
are a "hardening" measure, and when you have your very own distro, you
can fix the primary causes of problems |
| Solar_Diz |
3. finally,
it's not the security-related bells and whistles which make a system secure |
| Solar_Diz |
certain distributions
fall into the "secure" category by some definitions simply because they
integrate a variety of security tools (and are thus useful for security) |
| Solar_Diz |
however this
says nothing about how secure they are themselves |
| Solar_Diz |
(for those
joining, http://www.openwall.com/presentations/nordu2002-owl-html+images/) |
| Solar_Diz |
(slide 4) |
| Solar_Diz |
now, let's
introduce our distribution, Owl |
| Solar_Diz |
we intend
it as a security-enhanced server platform, and we based the distribution
on the following pieces of software: |
| Solar_Diz |
1. The Linux
kernel and its corresponding utilities |
| Solar_Diz |
2. (some of)
GNU software |
| Solar_Diz |
3. many BSD-derived
components, including those ported to Linux specifically for use in Owl |
| Solar_Diz |
4. other free
software from various authors (e.g., Postfix) |
| Solar_Diz |
5. free software
developed by openwall team members, including specifically for Owl |
| Solar_Diz |
more on the
third and fifth categories later |
| Solar_Diz |
(for those
joining, there's an Owl box to play with: |
| Solar_Diz |
ssh uninet.tmp.openwall.com |
| Solar_Diz |
l: uninet |
| Solar_Diz |
p: franc&gather.school |
| Solar_Diz |
please be
polite as i have no time to track abuse during the talk) |
| Solar_Diz |
(slide 5) |
| Solar_Diz |
now, the features
Owl offers: |
| Solar_Diz |
first, it
may be used as a base for installing whatever software is generally available
for GNU/*/Linux systems, -- including commercial and closed-source |
| Solar_Diz |
we even try
to provide package-level compatibility for installing packages intended
for RHL on Owl, where that doesn't conflict with our more important goals |
| Solar_Diz |
then, we try
to include a growing set of integrated Internet services |
| Solar_Diz |
right now
only a relatively small set is available, -- due to our very strict requirements
for the design and quality of network services (more on that later) |
| Solar_Diz |
Owl also includes
a complete build environment ("make buildworld") with which you can easily
rebuild the entire system from source, more on that later |
| Solar_Diz |
finally, we
support multiple architectures |
| Solar_Diz |
currently
that's x86, sparc, and alpha |
| Solar_Diz |
(although
during -current branch development the published binary packages for non-x86
architectures are often behind the real -current, that may change to follow
demand) |
| Solar_Diz |
(for those
joining, http://www.openwall.com/presentations/nordu2002-owl-html+images/) |
| Solar_Diz |
(slide 6) |
| Solar_Diz |
now, our approach
to security |
| Solar_Diz |
1. software
design and code quality are our first priority; some of what we mean by
"quality" is to be defined later on, the rest is subjective ;-) |
| Solar_Diz |
2. we do proactive
source code review of software we package |
| Solar_Diz |
pieces of
code which are typically run with privileges greater than those of a regular
user and/or typically process data obtained over a network are audited
before the corresponding software component is included |
| Solar_Diz |
this applies
to: |
| Solar_Diz |
- relevant
code paths in many of the system libraries |
| Solar_Diz |
- all SUID/SGID
programs |
| Solar_Diz |
- all daemons
and network services |
| Solar_Diz |
other pieces
of source code may be reviewed when the software component is already a
part of Owl |
| Solar_Diz |
(slide 7,
continuation of our approach to security) |
| Solar_Diz |
3. we apply
software modifications in order to: |
| Solar_Diz |
- apply the
least privilege principle |
| Solar_Diz |
- introduce
privilege separation |
| Solar_Diz |
what exactly
we do will be illustrated on further slides |
| Solar_Diz |
4. we provide
a safe default configuration for everything that is configurable |
| Solar_Diz |
dangerous
features, if any, need to be enabled explicitly |
| Solar_Diz |
5. as the
project evolves, many of the software components will be replaced with
ones of our own |
| Solar_Diz |
for some,
that has already been happening |
| Solar_Diz |
for example,
at first we used Linux-PAM's pam_unix (or actually pam_pwdb) to provide
authentication of Unix accounts, even though we knew perfectly well that
it is something to be replaced |
| Solar_Diz |
now we've
switched to our own, pam_tcb |
| Solar_Diz |
there're other
examples |
| Solar_Diz |
(slide 8,
even more continuation of our approach to security;-) |
| Solar_Diz |
6. we provide
certain policy enforcement and integrity checking capabilities in the distribution |
| Solar_Diz |
in particular,
all of our login services are capable of dealing with account and password
aging information |
| Solar_Diz |
when passwords
are changed (through whatever service), strong passwords are enforced (as
configurable by the administrator) |
| Solar_Diz |
we also include
a port of BSD's mtree(8) utility to do filesystem integrity checking |
| Solar_Diz |
7. we include
strong cryptography within core OS components |
| Solar_Diz |
well, today
this is nothing too exciting: many other distributions do as well |
| Solar_Diz |
this of course
means things such as openssl and openssh are an essential part of the system
(and our port of mtree is made to use openssl) |
| Solar_Diz |
but to mention
a few pieces which others don't do: we also have an improved password hashing
framework implemented in our glibc/libcrypt (please refer to crypt(3),
the man page i wrote, on the owl box) |
| Solar_Diz |
and we have
cryptographically random id's in the resolver (DNS) |
| Solar_Diz |
(just to remind,
the owl box is at: |
| Solar_Diz |
ssh uninet.tmp.openwall.com |
| Solar_Diz |
l: uninet |
| Solar_Diz |
p: franc&gather.school |
| Solar_Diz |
once again
please be polite, no time to track abuse) |
| Solar_Diz |
(those who
ran into an rlimit, -- please re-login, rlimits increased) |
| Solar_Diz |
8. we also
apply "hardening" to reduce likelihood and/or impact of successful real-world
attacks on insecure third-party software one might install on the system |
| Solar_Diz |
this is not
limited to the optional kernel patches (yes, they're optional and relatively
unimportant on Owl, except when they fix a kernel vulnerability) |
| Solar_Diz |
for example,
in various system libraries we also have certain "hardening" for the case
of uses from SUID/SGID programs |
| Solar_Diz |
this includes
glibc, ncurses, libtermcap, openssl |
| Solar_Diz |
9. finally,
we aim to have a wide range of security tools available for use "out of
the box" |
| Solar_Diz |
right now
there're not so many but that will be changing once we're done with what
we consider are more important problems to work on |
| Solar_Diz |
with our ISO
images providing a live multi-user networked system, Owl may also be considered
a replacement for Trinux for when a CD drive is available |
| Solar_Diz |
(slide 9,
the build environment) |
| Solar_Diz |
the Owl userland
is maintained similarly to *BSD ports/packages and may be rebuilt with
one simple command, "make buildworld" |
| Solar_Diz |
as you can
see, the implementation of "make buildworld" is very different from that
seen on *BSD |
| Solar_Diz |
we have two
source trees: |
| Solar_Diz |
one "native"
tree, with our own software and build specs and patches to third-party
software we package |
| Solar_Diz |
and the other
"sources" tree, with third-party software in the form of tarballs or such |
| Solar_Diz |
some packages
are built from both trees (*BSD-port like) |
| Solar_Diz |
others, which
we fully maintain ourselves, exist entirely in the native tree |
| Solar_Diz |
during the
buildworld, several builder processes may be created for efficient builds
on milti-processor machines |
| Solar_Diz |
and as a result
of the buildworld RPM packages are produced |
| Solar_Diz |
why RPM, you
ask? |
| Solar_Diz |
well, we recognize
that one reason people pick Linux over a *BSD is they want to install software
intended for Linux |
| Solar_Diz |
much of it
comes in RPM format these days |
| Solar_Diz |
and we'd better
provide reasonable dependency handling for those packages |
| Solar_Diz |
for those
who dislike RPM as much as I do, -- you don't have to even be aware that
there're RPM's between the buildworld and the installworld |
| Solar_Diz |
you just run
the two commands ;-) |
| Solar_Diz |
then, the
package manager is one of those things we'd like to replace with our own
once/if we have the time |
| Solar_Diz |
(slide 10,
the software we developed for Owl) |
| Solar_Diz |
(for those
joining, the slides are at http://www.openwall.com/presentations/nordu2002-owl-html+images/) |
| Solar_Diz |
first, the
portable software we developed and use in Owl: |
| Solar_Diz |
several PAM
modules: pam_mktemp, pam_passwdqc, pam_userpass |
| Solar_Diz |
(you may issue
"rpm -qi" on those on the owl box, |
| Solar_Diz |
ssh uninet.tmp.openwall.com |
| Solar_Diz |
l: uninet |
| Solar_Diz |
p: franc&gather.school) |
| Solar_Diz |
pam_mktemp
provides safe per-user temporary directories and sets $TMPDIR accordingly |
| Solar_Diz |
pam_passwdqc
is our password strength checking/enforcement module with support for passphrases
and also randomly-generated ones |
| Solar_Diz |
please refer
to /usr/doc/pam_passwdqc-*/README on the box or http://www.openwall.com/passwdqc/ |
| Solar_Diz |
(questions) |
| Solar_Diz |
(on #qc that
is) |
| Solar_Diz |
other portable
software we wrote and include in Owl is: popa3d, scanlogd, john, and libnids |
| Solar_Diz |
popa3d is
the POP3 server, more on its design on a separate slide |
| Solar_Diz |
scanlogd is
a simple port scan detection tool |
| Solar_Diz |
john is a
password cracker/checker used to identify weak passwords |
| Solar_Diz |
and libnids
is Nergal's (hi Nergal) low-level networking library which does IP defragmentation
and TCP stream reassembly, to be used for intrustion detection and traffic
analysis |
| Solar_Diz |
then, the
"semi-portable" software we have: |
| Solar_Diz |
crypt_blowfish,
the password hashing framework you could see explained in crypt(3) on the
Owl box |
| Solar_Diz |
it also includes
my implementation of bcrypt, the password hashing algorithm originally
designed for OpenBSD |
| Solar_Diz |
which we of
course use as the default |
| Solar_Diz |
and the tcb
suite, work by Nergal and me, which consists of libtcb, libnss_tcb, and
pam_tcb |
| Solar_Diz |
i will hopefully
describe that in detail later |
| Solar_Diz |
(questions/comments
on #qc) |
| Solar_Diz |
then, the
Owl-specific software we developed: |
| Solar_Diz |
owl-control,
a framework for controlling (enabling/disabling and not only that) of system
facilities without having to install/uninstall their corresponding packages |
| Solar_Diz |
the owl-control
facilities include things like: |
| Solar_Diz |
jill!root:~#
control |
| Solar_Diz |
chage
restricted (public restricted) |
| Solar_Diz |
chfn
restricted (public restricted) |
| Solar_Diz |
chsh
restricted (public restricted) |
| Solar_Diz |
crontab
public (public restricted) |
| Solar_Diz |
as well as
certain servics: |
| Solar_Diz |
postfix
local (server
local) |
| Solar_Diz |
sftp
disabled (enabled disabled) |
| Solar_Diz |
and some less
trivial cases: |
| Solar_Diz |
sftp
disabled (enabled disabled) |
| Solar_Diz |
su
wheelonly (public wheel wheelonly restricted) |
| Solar_Diz |
(this is not
an exhaustive list) |
| Solar_Diz |
well, and
of course the startup scripts, the build environment, and so on are all
Owl-specific |
| Solar_Diz |
(slide 11,
the ported software) |
| Solar_Diz |
(the slides
are at http://www.openwall.com/presentations/nordu2002-owl-html+images/) |
| Solar_Diz |
several software
components have been ported from OpenBSD, with our usual source code review
and modifications |
| Solar_Diz |
this includes: |
| Solar_Diz |
mailx (/bin/mail) |
| Solar_Diz |
mtree, --
and we actually build the initial filesystem hierarchy with it |
| Solar_Diz |
telnet and
telnetd, -- with modifications to introduce privilege separation, more
on that later |
| Solar_Diz |
Vixie Cron,
-- with modifications for SGID crontab(1) |
| Solar_Diz |
(it's not
SUID root on Owl, it doesn't need to be) |
| Solar_Diz |
(slide 12) |
| Solar_Diz |
the software
we have modified: |
| Solar_Diz |
that's essentially
all of it |
| Solar_Diz |
- we have
on average 4 patch files per package |
| Solar_Diz |
- (the most
important) half of the patches originate in Owl |
| Solar_Diz |
- the other
half has been imported from various other distributions, including *BSD's,
-- |
| Solar_Diz |
-- with appropriate
credit given in each patch file name |
| Solar_Diz |
(this also
lets us and others track where a patch came from) |
| Solar_Diz |
(slide 13,
the crontab / crond interaction) |
| Solar_Diz |
from now on,
i'll have to be brief _assuming_ that you're looking at the slides or we
won't finish in time :-) |
| Solar_Diz |
http://www.openwall.com/presentations/nordu2002-owl-html+images/ |
| Solar_Diz |
well, we have
modified crontab and crond such that: |
| Solar_Diz |
the cron spool
directory is made writable to group crontab, mode 1730 |
| Solar_Diz |
crontab(1)
is installed SGID crontab |
| Solar_Diz |
(you may see
that on the Owl box) |
| Solar_Diz |
crond(8) doesn't
blindly trust its spool directory |
| Solar_Diz |
rather, it
makes such each cron job file is owned by the user the job is meant to
run as |
| Solar_Diz |
thus, a compromise
of group crontab would at most (in the absense of a second bug) result
in the ability to play DoS attacks against crond |
| Solar_Diz |
no root compromise
:-) |
| Solar_Diz |
(slide 14,
syslogd architecture) |
| Solar_Diz |
well, our
syslogd has been modified (based on work by Chris Wing of CAEN Linux) to
run as non-root |
| Solar_Diz |
on Owl, it
is started as the dedicated pseudo-user and group, syslogd |
| Solar_Diz |
in order to
be able to re-open the log files on SIGHUP, usually after the logs have
been rotated, the log rotator must make them writable to user or group
syslogd (ours does) |
| Solar_Diz |
(slide 15,
klogd architecture) |
| Solar_Diz |
similarly,
our klogd has been patched to support running as non-root and chrooted |
| Solar_Diz |
you may see
the updated man pages for both syslogd and klogd on the Owl box, |
| Solar_Diz |
ssh uninet.tmp.openwall.com |
| Solar_Diz |
l: uninet |
| Solar_Diz |
p: franc&gather.school |
| Solar_Diz |
by default,
we run klogd as user/group klogd and chrooted to /var/empty |
| Solar_Diz |
again, a possible
bug in klogd (and there has been some in the past) would no longer result
in a root compromise |
| Solar_Diz |
(slide 16,
popa3d architecture) |
| Solar_Diz |
that is an
example of privilege separation implemented in a service |
| Solar_Diz |
we currently
do that for all network services except SSH; that will change soon as Niels
Provos has been working hard on privilege separation for OpenSSH |
| Solar_Diz |
of the services
we have, there're slides for popa3d, telnetd, and vsftpd |
| Solar_Diz |
there's no
slide for Postfix although it uses privilege separation and is running
chrooted on Owl, too |
| Solar_Diz |
(and we got
certain fixes into official Postfix for that privilege separation to be
more effective) |
| Solar_Diz |
so, the popa3d
architecture |
| Solar_Diz |
as can be
seen on the slide, popa3d forks into two processes during the authorization
state |
| Solar_Diz |
no user input
directly reaches the root-privileged part |
| Solar_Diz |
then, after
the user is authenticated, popa3d is running as that user |
| Solar_Diz |
this means
that popa3d never subjects its root privileges to the risk of remote attacks
_directly_ (indirect attacks may still be possible but will very likely
require at least two bugs, not one) |
| Solar_Diz |
(slide 17,
telnetd architecture) |
| Solar_Diz |
the telnetd
I have ported from OpenBSD (post-3.0) |
| Solar_Diz |
the modifications
illustrated on the slide are similar to those Chris Evans has demonstrated
in his NetKit telnetd patches, although the code is different |
| Solar_Diz |
the idea is
similar: a bug in telnet protocol handling (a fairly complicated task)
shouldn't result in a direct root compromise, even though telnetd needs
to do parts of its work as root |
| Solar_Diz |
how that is
achieved can be seen on the slide |
| Solar_Diz |
(slide 18,
vsftpd architecture) |
| Solar_Diz |
vsftpd is
Chris Evans' FTP server, we use it on Owl :-) |
| Solar_Diz |
it has privilege
separation implemented from the very beginning |
| Solar_Diz |
please refer
to the slide for details |
| Solar_Diz |
(it is more
complicated than the popa3d and telnetd cases, and we have no time to go
into that) |
| Solar_Diz |
(slide 19,
an introduction into traditional password shadowing) |
| Solar_Diz |
well, as most
of you probably know, with traditional password shadowing all password
hashes and aging information of all users go into a single file, /etc/shadow |
| Solar_Diz |
this means
that: |
| Solar_Diz |
passwd(1)
has to be SUID root in order to be able to write new passwords into that
file |
| Solar_Diz |
chage(1) has
to possess the privilege to read all of the shadow file |
| Solar_Diz |
as a result,
a 'passwd' process compromise is fatal |
| Solar_Diz |
(it is a root
compromise) |
| Solar_Diz |
and the problem
cannot be fixed by assigning a dedicated user for /etc/shadow accesses
(another owner of the file) |
| Solar_Diz |
this is because
that user would be able to change any other user's password and thus would
effectively be able to do all root can |
| Solar_Diz |
(slide 20,
tcb - our alternative to shadow) |
| Solar_Diz |
- each user
is assigned a separate shadow file |
| Solar_Diz |
- each user
is the owner of their shadow file |
| Solar_Diz |
- access to
shadow files is group-restricted to allow for password policy enforcement |
| Solar_Diz |
the move to
tcb is transparent for existing applications which rely on interfaces such
as getspnam(3) (and thus on NSS) or PAM |
| Solar_Diz |
no modifications
to application sources are needed |
| Solar_Diz |
tcb is currently
enabled on the Owl box: |
| Solar_Diz |
ssh uninet.tmp.openwall.com |
| Solar_Diz |
l: uninet |
| Solar_Diz |
p: franc&gather.school |
| Solar_Diz |
you may look
at the permissions on /usr/bin/passwd, /etc/tcb |
| Solar_Diz |
and i'll now
let you change the password to see that it indeed does work (as well as
how our password strength enforcement works) |
| Solar_Diz |
Minimum Password Age [365]: -1 |
| Solar_Diz |
ok, but please
paste the new password in here if you do change it |
| Solar_Diz |
(slide 21,
the filesystem layout) |
| Solar_Diz |
well, just
look at the slide :-) |
| Solar_Diz |
http://www.openwall.com/presentations/nordu2002-owl-html+images/ |
| Solar_Diz |
we also use
the per-user directories for space and lock files which are needed
during password change and account management |
| Solar_Diz |
there's a
tcb(5) man page, as well as other relevant man pages referenced from it |
| Solar_Diz |
(slide 22,
the privileges required for tcb) |
| Solar_Diz |
(i know we're
out of time, finishing in 5-10 minutes after which Kurt will give his talk:-) |
| Solar_Diz |
passwd(1)
is made SGID shadow |
| Solar_Diz |
chage(1) is
SGID shadow |
| Solar_Diz |
a possible
compromise would only let one bypass password policy enforcement for their
own account |
| Solar_Diz |
there's support
for group "auth" should the need arise to grant a process read access to
all of the password hashes at once (this is what group "shadow" used to
do) |
| Solar_Diz |
finally, with
such a scheme, there may be no real need for any SUID binaries on the entire
system, yet leaving the system perfectly usable |
| Solar_Diz |
(passwd works,
crontab works, and so on) |
| Solar_Diz |
(slide 23,
the components of the tcb suite) |
| Solar_Diz |
- libtcb,
the auxiliary library used by almost all of the tcb suite, -- it provides
functions for locking and accessing tcb shadow files safely |
| Solar_Diz |
(we can't
blindly trust the /etc/tcb subdirectories, else a group shadow compromise
could be extended into a root compromise) |
| Solar_Diz |
- libnss_tcb,
the NSS module |
| Solar_Diz |
it provides
getspnam(3) and related functions, only making them access the /etc/tcb
hierarchy rather than /etc/shadow |
| Solar_Diz |
finally, the
/etc/tcb/*/shadow files themselves are accessed with the proper effective
credentials and their contents are treated as untrusted input by root-privileged
parts of the system |
| Solar_Diz |
(slide 24,
more tcb components) |
| Solar_Diz |
- pam_tcb,
the PAM module |
| Solar_Diz |
it provides
functionality for all four PAM management groups (authentication, accounting,
session and password management) |
| Solar_Diz |
it supports
/etc/passwd, /etc/shadow, /etc/tcb/ directory structure, NIS, and NIS+
for password changes |
| Solar_Diz |
(the other
parts aren't limited to those authentication databases as NSS is used and
other NSS modules may be provided) |
| Solar_Diz |
it supports
arbitrary password hashing methods, with no need to recompile if you add
a new one |
| Solar_Diz |
this is possible
due to our improved password hashing framework in glibc/libcrypt |
| Solar_Diz |
please refer
to crypt_gensalt(3) man page on the Owl box: |
| Solar_Diz |
ssh uninet.tmp.openwall.com |
| Solar_Diz |
l: uninet |
| Solar_Diz |
p: franc&gather.school |
| Solar_Diz |
(hope the
password is still valid since after i've let you folks change it) |
| sarnold |
(it appears
it is :) |
| Solar_Diz |
it also optionally
forks child processes to deal with sensitive information to keep the application's
address space clean |
| Solar_Diz |
and of course
it's backwards compatible with Linux-PAM pam_unix and pam_pwdb but offers
additional functionality and better code quality |
| Solar_Diz |
(slide 25,
the remaining tcb components) |
| Solar_Diz |
- tcb_convert
and tcb_unconvert |
| sarnold |
new passwd:
surf-exceed;lemon |
| Solar_Diz |
these allow
for easy conversion between /etc/tcb/* and traditional /etc/shadow databases |
| Solar_Diz |
please refer
to the man pages for those for instructions on how to use them and what
other steps need to be done for conversion |
| Solar_Diz |
- the shadow
suite utilities |
| Solar_Diz |
non-trivial
patching has been applied to the sources of most shadow suite utilities |
| Solar_Diz |
the invocation
syntax remained unchanged (with few exceptions to access certain tcb-specifics) |
| Solar_Diz |
(such as,
with "vipw -s" you now have to specify a username) |
| Solar_Diz |
(that's only
when in tcb mode, of course) |
| Solar_Diz |
- a setting
in /etc/login.defs specifies whether the utilities should adhere to the
tcb scheme or be backwards-compatible |
| Solar_Diz |
(slide 26,
further information) |
| Solar_Diz |
please refer
to the Owl homepage at http://www.openwall.com/Owl/
for further information |
| Solar_Diz |
this presentation
has been prepared by me and Nergal, who is also the primary author of the
tcb suite i've just described :-) |
| Solar_Diz |
now, i would
let you ask questions but i know we're out of time :-( |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA SPLA |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA SPLA |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA SPLA |
| viZard |
(virtual applause)
;-) |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA SPLA |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA SPLA |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA PLAS |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA PLAS |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| seifried |
you can take
a few more mins, I'm gonna try and keep mine short |
| sarnold |
clap clap
clap clap |
| sarnold |
clap clap
clap clap |
| sarnold |
clap clap
clap clap |
| sarnold |
clap clap
clap clap |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA PLAS |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| sarnold |
clap clap
clap clap |
| MJesus |
spasibo Solar,
spasibo nergal |
| viZard |
riels user
get +om automatically |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| sarnold |
yes, one thing
that should be pointed out ... |
| sarnold |
solar designer
has contributed a _huge_ amount of security fixes to opensource projects
over the years |
| Solar_Diz |
could we perhaps
create #owl for the questions? |
| cronos |
thanks Solar_Diz
for sharing your knowledge with us and takeing the time to be here. |
| Solar_Diz |
thank you
everyone for listening, smart questions, and for being so polite with the
victim Owl box |
| sarnold |
:) |
| viZard |
nice linux-2.2.20
Owl box :D |
| viZard |
i love it
! |
| viZard |
where can
i get one of those ? :) |
| cronos |
Solar_Diz
downlaod the CD from openwall |
| cronos |
i mean, the
iso |
| sarnold |
yes, #owl
is now available if you wish to discuss Openwall linux further :) |
| cronos |
http://www.openwall.com/Owl/ |
