From cperciva at freebsd.org Tue Jun 3 03:31:31 2008 From: cperciva at freebsd.org (FreeBSD Security Officer) Date: Tue Jun 3 03:31:34 2008 Subject: FreeBSD supported branches update Message-ID: <20080603033131.GB90341@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, The branches supported by the FreeBSD Security Officer have been updated to reflect recent EoL (end-of-life) events. The new list is below and at . FreeBSD 5.5, FreeBSD 6.1, and FreeBSD 6.2 have `expired' and are no longer supported effective June 1, 2008. Users of these releases are advised to upgrade promptly to FreeBSD 6.3 or FreeBSD 7.0, either by downloading an updated source tree and building updates manually, or (for i386 and amd64 systems) using the FreeBSD Update utility as described in the FreeBSD 6.3 and FreeBSD 7.0 release announcements. This marks the end of support by the FreeBSD Security Team for the FreeBSD 5-STABLE branch, and at this time support for running software from the ports tree on FreeBSD 5.x is also ceasing: Packages for binary installations will no longer be built for FreeBSD 5.5, building ports from source on FreeBSD 5.x will no longer be supported, and the ports INDEX will no longer be built and made available via portsnap or the 'make fetchindex' target. Patches for individual ports specific for their functioning on FreeBSD 5.5 may still be accepted at the discretion of the port maintainer. [Excerpt from http://security.freebsd.org/ follows] FreeBSD Security Advisories The FreeBSD Security Officer provides security advisories for several branches of FreeBSD development. These are the -STABLE Branches and the Security Branches. (Advisories are not issued for the -CURRENT Branch.) * There is usually only a single -STABLE branch, although during the transition from one major development line to another (such as from FreeBSD 5.x to 6.x), there is a time span in which there are two -STABLE branches. The -STABLE branch tags have names like RELENG_6. The corresponding builds have names like FreeBSD 6.1-STABLE. * Each FreeBSD Release has an associated Security Branch. The Security Branch tags have names like RELENG_6_1. The corresponding builds have names like FreeBSD 6.1-RELEASE-p1. Isses affecting the FreeBSD Ports Collection are covered in the FreeBSD VuXML document. Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or `Extended'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. The current designation and estimated lifetimes of the currently supported branches are given below. The Estimated EoL (end-of-life) column gives the earliest date on which that branch is likely to be dropped. Please note that these dates may be extended into the future, but only extenuating circumstances would lead to a branch's support being dropped earlier than the date listed. +--------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+-----------+--------+-----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |January 31, 2010 | |-----------+-----------+--------+-----------------+-----------------| |RELENG_6_3 |6.3-RELEASE|Extended|January 18, 2008 |January 31, 2010 | |-----------+-----------+--------+-----------------+-----------------| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |-----------+-----------+--------+-----------------+-----------------| |RELENG_7_0 |7.0-RELEASE|Normal |February 27, 2008|February 28, 2009| +--------------------------------------------------------------------+ [End excerpt] Colin Percival FreeBSD Security Officer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkhEe5MACgkQFdaIBMps37IXoQCbB3RkY/s2CA+o/OFkuC/1YvUV rY8An1JawL1x8DdUOlVUL0b2+9N4XZ2v =X+Zm -----END PGP SIGNATURE----- From 000.fbsd at quip.cz Tue Jun 3 22:33:29 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue Jun 3 22:33:34 2008 Subject: A simple rc.d jail patch to enable priority In-Reply-To: <20080225151304.nan0he4xcs8kk00w@webmail.leidinger.net> References: <20080224163005.GG15445@oak.pl> <20080225151304.nan0he4xcs8kk00w@webmail.leidinger.net> Message-ID: <4845C229.4020503@quip.cz> Alexander Leidinger wrote: > Quoting Jan Srzednicki (from Sun, 24 Feb 2008 17:30:05 > +0100): > >> Hello, >> >> I have written this tiny little patch to the jail rc.d script, which >> allows user to set jail nice value. It doesn't change any default >> behaviour. >> >> Can that make it to the trees? >> Patch attached. > > You need to provide documentation for it if you want that someone > considers it for inclusion into the tree. I took it and sent PR conf/124248 with patch for rc.d/jail, defaults/rc.conf and man5/rc.conf.5 Please let me know if commited, so I can update status of the patch on http://wiki.freebsd.org/Jails Miroslav Lachman From temp0607 at mail.securge.net Sun Jun 22 19:41:36 2008 From: temp0607 at mail.securge.net (michupitka) Date: Sun Jun 22 19:41:40 2008 Subject: disk label and geli encrypted slice Message-ID: <485EA493.1050601@mail.securge.net> Hello, I'm using geli on laptop PC with only one HDD. Disk is divided into two slices, ad0s1 and ad0s2. Second slice (ad0s2) is encrypted with GEOM ELI using two-factor authentication - passphrase plus keyfile on USB drive. FreeBSD is installed on ad0s2.eli and first slice is not used by this system so let's say that I've got a full disk encryption. Now my question - is it safe to keep backup of encrypted disk's label (dump of bsdlabel /dev/ad0s2.eli) on the same USB drive with keyfile? Information about partitions itself is not important for me, I don't feel like I have to keep it secret, but is it any advantage to attacker if she get her hands not only on keyfile but also on unencrypted BSD label and then gain access to still encrypted media? I'm deliberately omitting the fact that in this scenario attacker has access to unencrypted kernel or /boot directory on USB drive so he could trojan it or do other nasty things to obtain my passphrase later. Michal -- "I do not fear computers. I fear the lack of them." -Isaac Asimov