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 youat_private' 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 (jonat_private) 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 <jonat_private> -- Jon Lasser (410)383-7962 http://www.tux.org/~lasser/ Work: jonat_private Home: jonat_private "The more you drive, the less intelligent you get." -- Repo Man
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:48:08 PDT