[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
[Off-topic] Announcement: Bastille Linux (fwd)
****** message to minivend-users from Birgitt Funk <birgitt@tux.org> ******
Hi,
as many of you are running Linux servers I thought this might
be of interest.
Birgitt Funk
---------- Forwarded message ----------
Date: Thu, 3 Jun 1999 14:59:51 -0400
From: J. Lasser <jon@umbc.edu>
To: Bastille-linux-announce@lists.bastille-linux.org,
security-audit@ferret.lmh.ox.ac.uk, John Gilmore <gnu@toad.com>,
Wichert Akkerman <wichert@cs.leidenuniv.nl>,
Linux Weekly News <lwn@lwn.net>,
Mid-Atlantic Linux Users Group <ma-linux@tux.org>,
UMBC Linux Users Group <umbclinux@lists.umbc.edu>,
Rob Malda <malda@slashdot.org>, Bugtraq <bugtraq@netspace.org>,
Freshmeat <scoop@freshmeat.net>,
Old Bay SAGE <oldbaysage@lists.oldbaysage.org>,
DC-SAGE <dc-sage@dc-sage.org>
Subject: Announcement: Bastille Linux
June 3, 1999
Work on the Bastille Linux distribution is commencing!
- ------------------------------------------------------
[ I'll be at the USENIX Technical Conference in Monterey the second half
of next week (the 9th through the 11th), and will be leading a Secure
Linux BOF Thursday night from 7 to 8 PM. Everyone is welcome to attend;
the Bastille Linux distribution will be the primary topic for
discussion, but I welcome other bits too. ]
The company formerly known as VA Research, VA Linux Systems, has kindly
provided a website and FTP site for our project at:
http://www.bastille-linux.org/
(and ftp.bastille-linux.org as well).
Right now, that page has the (very!) preliminary version of our
development roadmap and a link to:
http://lists.bastille-linux.org/mailman/listinfo
where our mailing lists are run.
We currently have two mailing lists: Bastille-linux-announce, a
moderated list for announcements regarding the project, and
Bastille-linux-discuss, an unmoderated list for discussion of the
project.
To subscribe to the announcement list, please visit the above website or
send a message to:
Bastille-linux-announce-request@bastille-linux.org
with 'subscribe you@example.net' in the body of the message (no quotes).
To subscribe to the discussion list, please send the above message to:
Bastile-linux-discuss-request@bastille-linux.org
The announce list is NOT subscribed to the discussion list, so please
subscribe to both if you're so inclined. If you wish to subscribe to the
digest version of the list, it's probably simplest to subscribe directly
from:
http://lists.bastille-linux.org/mailman/listinfo
The mailing lists are archived at:
http://lists.bastille-linux.org/pipermail/bastille-linux-discuss/
and
http://lists.bastille-linux.org/pipermail/bastille-linux-announce/
Our distribution is aimed primarily at individual users who are less
knowledgeable about security than experts would be. By securing the
default configuration, inexperienced users will be able to run secure
services without having to become security gurus.
The target for our first distribution is admins who distribute CDs to
users who are responsible for their own systems. This will be useful
in, say, universities, so that admins like myself can hand a Linux CD to
a user without entering a state of complete and utter panic, as well as
in corporations without strong IS control of all PC resources.
User-administered systems are not our only target; we intend our
distribution to be useful to experienced administrators running
single-purpose secure servers and to home users for whom security has
traditionally been an afterthought.
For reasons outlined in our project roadmap (available at our homepage)
our distribution will be based on Red Hat Linux v6.0.
Currently, I'm looking for leaders for the following aspects of the
project:
- - 'Gimme' fixes: All the easy, simple, turn SUID off or change
config file fixes which should be completed immediately. I need
an individual willing to merge our several lists of such
problems, create a checklist, and coordinate individuals' fixed
packages. I (and, I'm sure, others) will be more than happy to
actually produce the fixed packages, but a coordinator is
needed.
- - 'Harden' script: We have a 'harden' script or two at our
disposal which need to be adapted to our environment and the
needs of our users. These scripts need to be assessed, and their
useful parts unified into a single harden script which can be
run immediately following an install.
- - Cryptography: We intend to make strong cryptography a meaningful
part of the distribution. This includes SSH, S/WAN, PGP, and
other useful tools. We need to compile a list of useful crypto
parts and oversee the creation of packages for these programs.
- - New Tools: We need a front-end to make kickstart installs more
easily configured to not run unnecessary daemons and to install
a more tightly-controlled set of packages. I envision a
front-end to create useful Kickstart files meeting specific
criteria. A back-end tool, mkkickstart, already does some of
what we need, but we should make this accessible to non-experts.
- - Other Tools: Many other security tools exist from which Bastille
Linux could benefit. These need to be examined, packaged, and
integrated into our distribution.
- - Installer: We need a couple of (mostly minor) changes to the
Red Hat install program, including the ability to include the
kickstart file on CDs, to make installation simpler in certain
environments.
- - Auditing: We need a list of criteria for auditing source code
for the kernel and applications, and an individual to maintain
a checklist for what has been audited. This way, we actually
have some records as to what has been fixed or changed, and
what may not be secure. (I don't expect all of this to be done
for the 1.0 release, but there's no time like the present to
get started.) The Linux Security Audit project mailing list is
quite useful, and the auditing coordinator is expected to work
closely with the LSAP folk. The LSAP FAQ can be found at
http://www-jcr.lmh.ox.ac.uk./~security/
- - Standards: While not our highest priority for the 1.0 release,
we should track applicable standards as closely as possible.
This means attempting compliance with the LSB project, as it
turns out new standards, and (if we can manage), whatever sorts
of distribution-level Posix stuff we need to do. (Using the
Bash 2.0 shell, for example, as opposed to the 1.x version,
based on 2.0's nearly complete Posix compliance. The standards
coordinator is expected to try to keep abreast of existing
standards and to track our compliance with them. This includes
various security standards, such as the Controlled Access
Protection Profile (NSA's C2-equivalent PP). If deemed
necessary, we could split the standards into security standards
and other standards, so that they could be coordinated more
easily.
- - Documentation: We need to, at a minimum, produce a detailed list
of changes in our distribution from a stock Red Hat 6
distribution, and to produce user-level documentation for any
tools we build or modify. Somebody needs to keep track of these
changes and find folks to document them.
- - Updates: Once our v1.0 is released, somebody will need to
produce fixes for new holes found and to make announcements
regarding our fixes.
- - Web: We need folks willing to keep the web site up-to-date,
preferably by writing some tools to automate as much as possible
what changes have been or need to be made. Thanks to Ben Woodard
at VA Linux Systems, soon we'll have our distribution accessible
through CVS and we'll have a bug-tracking package installed at
the website. We need to make this info as useful and as
presentable as possible.
- - QA: We need somebody willing to hold _somebody_, _anybody_
responsible for fixing the bugs reported through our bug
tracking package. This may mean fixing it by oneself if the
appropriate maintainer is not willing or not able to do so, or
it may mean tracking me down and making _me_ do it. :-)
This is, of course, a lot of work. In addition to all of this, I intend
to personally be the overall coordinator of all these functions, to
provide a beta-test site for the project, and to be liaison with other
Linux distributions.
This brings up the question of our relationship with other
distributions. I doubt that Red Hat will be interested in much of our
work, but I intend to keep in communication with them, especially on
security-related issues. Although our distribution is not going to be
based on Debian, we are working from a common code base, for the most
part, and I would like to share fixes with them directly.
Finally, there are several other secure Linux projects in development.
kha0s Linux and the (as-yet-unnamed) Secure Linux distribution project
coordinated by Le Reseau just starting development and aimed squarely at
servers, and to build it from the ground up. This is a very important
project, but it differs from ours in that our system is intended for
general use by a relatively unschooled public. We plan on closely
coordinating with the project hosted by Le Reseau (refereed by Rik van
Riel) as much as possible. The kha0s Linux project appears to be
dormant, but we will attempt to coordinate with them as well.
Several other groups, including the TrinityOS folk, Chris Schanzle's
group at NIST, and Kurt Seifried's Rebar for RedHat project have all
done work on securing Red Hat Linux-based distributions. Those folk are
all (I believe) on the list, and I look forward to integrating their
work into our own. Mr. Seifried in particular has suggested that we
merge our efforts, and we look forward to his participation in our
mutual project.
As I have already said, this is a lot of work. However, I truly believe
it's important work, and based on the number of people who seem willing
to work on it, I think that most folk agree. Now it's time to prove we
care by doing the work.
Please feel free to contact me (jon@umbc.edu) if you wish to take on any
of the leadership roles outlined above. Please include a brief list of
your qualifications on the off-chance that more than one person wants
any particular job. I regret that my decisions on areas of
responsibility may appear arbitrary, but we must get this project
underway.
Security is, among many other things, an iterative process; as there
will always be new layers of security enhancements, we merely need to be
open to learning from our mistakes. (Security is also a relative term:
secure as compared to what and for what purpose are questions we'll do
our best to answer as well.)
Thank you for taking the time to read this excessively long message, and
thank you in advance for your participation and response. Thanks
especially to Alan Paller and Rob Kolstad at the SANS institute for
supporting this work, to my boss Andy Johnston at the University of
Maryland, Baltimore County (UMBC) for allowing me to do this on company
time, and to Ben Woodard over at VA Linux Systems for making our
Internet Presence a reality and coordinating huge portions of this work.
Jon Lasser <jon@umbc.edu>
- --
Jon Lasser (410)383-7962 http://www.tux.org/~lasser/
Work: jon@umbc.edu Home: jon@lasser.org
"The more you drive, the less intelligent you get." -- Repo Man
------- End of forwarded message -------
-
To unsubscribe from the list, DO NOT REPLY to this message. Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list
