[OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available
Matt Vander Werf
mvanderw@nd.edu
Sat, 13 Oct 2018 14:14:06 -0400
--0000000000009d1f7d0578202dfe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
As far as I know, I don't believe support for RPMs has been dropped. From
my understanding, it's just a matter of who does the release and if they
have access to RPM-based systems to make the source RPM (SRPM) for said
release (but I could be wrong).
If the SRPM doesn't get put out with the release, we essentially follow the
instructions Richard sent, with a couple minor differences.
The latest instructions from OpenAFS for how to create RPMs is here:
https://wiki.openafs.org/devel/HowToBuildOpenAfsRpmPackages/ (very similar
to Richard's).
We use those instructions to create a SRPM (created by the 'make srpm'
line) and then create our RPM packages from that SRPM (we have a process
already for building RPMs from a SRPM, but the rpmbuild command on the link
above works too).
This almost always works well for us on RHEL 6 and RHEL 7 systems (and
usually Fedora systems too).
Hope this helps!
Thanks.
--=20
Matt Vander Werf
HPC System Administrator
University of Notre Dame
Center for Research Computing - Union Station
506 W. South Street
South Bend, IN 46601
On Fri, Oct 12, 2018 at 4:26 PM Richard Brittain <
Richard.Brittain@dartmouth.edu> wrote:
> On Fri, 12 Oct 2018, Sebby, Brian A. wrote:
>
> > Previous releases have included source RPMs that made it easier for us
> to build RPMs to deploy to our Red Hat-based servers.
> > I was hoping it maybe had just not yet been released yet, but there
> still isn=E2=80=99t a source RPM for 1.6.23. It looks like one
> > was built for 1.6.24.4, so I may just end up deploying that since we do
> not use any of the backup utilities. I know that
> > support for RPMs from OpenAFS is something that=E2=80=99s been discusse=
d for a
> long time, but I hadn=E2=80=99t seen any official announcement
> > (unless I missed it) that indicated that they would no longer be create=
d.
> >
> > For any other folks using Red Hat =E2=80=93 what are you doing for depl=
oying
> OpenAFS? Are there any repos out there equivalent to
> > the Ubuntu PPA?
>
> I've never managed to go from source tarball to clean RPMs. I found a wik=
i
> entry explaining how make a srpm, but it didn't work for me, at least for
> recent releases.
>
> However, there is a wiki entry explaining how to build from a git
> checkout, and that worked once I had all the GNU autotools in place. I'm
> sure this procedure does far more work than needed, but this is the brief
> summary of steps:
>
> $ cd ~/projects/openafs/1.8.2
> $ git clone git://git.openafs.org/openafs.git
> $ cd openafs
> $ git checkout openafs-stable-1_8_2
> $ ./regen.sh
> $ ./configure --enable-transarc-paths --enable-checking
> --enable-supergroups
> $ make dist
> $ make srpm
> $ rpmbuild --rebuild -ba --define "_topdir `pwd`/rpmbuild" --with kauth
> packages/openafs-1.8.2-1.src.rpm
> $ cd rpmbuild/x86_64/
>
> - copy the resulting RPMs to local distribution point.
>
> This worked cleanly on RHEL6 and RHEL7
>
> Richard
>
> > Brian
> >
> >
> >
> > --
> >
> > Brian Sebby (sebby@anl.gov) | Information Technology Infrastructure
> >
> > Phone: +1 630.252.9935 | Business Information Services
> >
> > Cell: +1 630.921.4305 | Argonne National Laboratory
> >
> >
> >
> >
> >
> > From: <openafs-info-admin@openafs.org> on behalf of Benjamin Kaduk <
> kaduk@mit.edu>
> > Date: Tuesday, September 11, 2018 at 2:09 PM
> > To: <openafs-announce@openafs.org>
> > Cc: <openafs-devel@openafs.org>, <openafs-info@openafs.org>
> > Subject: [OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available
> >
> >
> >
> >
> >
> > The OpenAFS Guardians are happy to announce the availability of
> >
> > Security Releases OpenAFS 1.8.2 and 1.6.23.
> >
> > Source files can be accessed via the web at:
> >
> >
> >
> > https://www.openafs.org/release/openafs-1.8.2.html
> >
> > https://www.openafs.org/release/openafs-1.6.23.html
> >
> >
> >
> > or via AFS at:
> >
> >
> >
> > UNIX: /afs/grand.central.org/software/openafs/1.8.2/
> >
> > UNC: \\afs\grand.central.org\software\openafs\1.8.2\
> >
> > UNIX: /afs/grand.central.org/software/openafs/1.6.23/
> >
> > UNC: \\afs\grand.central.org\software\openafs\1.6.23\
> >
> >
> >
> > These releases include fixes for three security advisories,
> >
> > OPENAFS-SA-2018-001, OPENAFS-SA-2018-002, and OPENAFS-SA-2018-003.
> >
> >
> >
> > OPENAFS-SA-2018-001 only affects deployments that run the 'butc' utilit=
y
> >
> > as part of the in-tree backup system, but is of high severity for
> >
> > those sites which are affected -- an anonymous attacker could replace
> >
> > entire volumes with attacker-controlled contents.
> >
> >
> >
> > OPENAFS-SA-2018-002 is for information leakage over the network via
> >
> > uninitialized RPC output variables. A number of RPCs are affected,
> >
> > some of which require the caller to be authenticated, but in some cases
> >
> > hundreds of bytes of data can be leaked per call. Of note is that
> >
> > cache managers are also subject to (kernel) memory leakage via
> >
> > AFSCB_ RPCs.
> >
> >
> >
> > OPENAFS-SA-2018-003 is a denial of service whereby anonymous attackers
> >
> > can cause server processes to consume large quantities of memory for
> >
> > a sustained period of time.
> >
> >
> >
> > Please see the release notes and security advisories for additional
> details.
> >
> >
> >
> > The changes to fix OPENAFS-SA-2018-001 require behavior change in both
> >
> > butc(8) and backup(8) to use authenticated connections; old and new
> >
> > versions of these utilities will not interoperate absent specific
> >
> > configuration of the new tool to use the old (insecure) behavior.
> >
> > These changes also are expected to cause backup(8)'s interactive mode
> >
> > to be limited to only butc connections requiring (or not requiring)
> >
> > authentication within a given interactive session, based on the initial
> >
> > arguments selected.
> >
> >
> >
> > Bug reports should be filed to openafs-bugs@openafs.org.
> >
> >
> >
> > Benjamin Kaduk
> >
> > for the OpenAFS Guardians
> >
> >
> >
> >
> >
>
> -----
> Richard Brittain, Research ITC
> Information, Technology and Consulting,
> 37 Dewey Field Road, HB6219
> Dartmouth College, Hanover NH 03755
> Richard.Brittain@dartmouth.edu 603-646-2085
> http://rc.dartmouth.edu/
--0000000000009d1f7d0578202dfe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>As far as I know, I don't believe support for RPM=
s has been dropped. From my=20
understanding, it's just a matter of who does the release and if they=
=20
have access to RPM-based systems to make the source RPM (SRPM) for said rel=
ease (but I could be=20
wrong).<br></div><div><br></div><div><div>If the SRPM doesn't get put o=
ut with the release, we essentially follow the instructions Richard sent, w=
ith a couple minor differences.</div><div><br></div><div>The latest instruc=
tions from OpenAFS for how to create RPMs is here:=C2=A0<a href=3D"https://=
wiki.openafs.org/devel/HowToBuildOpenAfsRpmPackages/">https://wiki.openafs.=
org/devel/HowToBuildOpenAfsRpmPackages/</a> (very similar to Richard's)=
. <br></div><div><br></div><div>We use those instructions to create a SRPM =
(created by the 'make srpm' line) and then=20
create our RPM packages from that SRPM (we have a process already for=20
building RPMs from a SRPM, but the rpmbuild command on the link above works=
too).<br></div></div><div><br></div><div>This almost always works well for=
us on RHEL 6 and RHEL 7 systems (and usually Fedora systems too).<br></div=
><div><br></div><div>Hope this helps!<br></div><div><br></div><div>Thanks.<=
/div><div><br></div><div><div dir=3D"ltr" class=3D"m_6581866833793441051gma=
il_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div=
dir=3D"ltr"><div>-- <br></div><div>Matt Vander Werf<br>HPC System Administ=
rator<br>University of Notre Dame<br>Center for Research Computing - Union =
Station<br>506 W. South Street<br>South Bend, IN 46601<br></div></div></div=
></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, =
Oct 12, 2018 at 4:26 PM Richard Brittain <<a href=3D"mailto:Richard.Brit=
tain@dartmouth.edu" target=3D"_blank">Richard.Brittain@dartmouth.edu</a>>=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 12 Oct 2018, Sebby=
, Brian A. wrote:<br>
<br>
> Previous releases have included source RPMs that made it easier for us=
to build RPMs to deploy to our Red Hat-based servers.=C2=A0<br>
> I was hoping it maybe had just not yet been released yet, but there st=
ill isn=E2=80=99t a source RPM for 1.6.23.=C2=A0 It looks like one<br>
> was built for 1.6.24.4, so I may just end up deploying that since we d=
o not use any of the backup utilities.=C2=A0 I know that<br>
> support for RPMs from OpenAFS is something that=E2=80=99s been discuss=
ed for a long time, but I hadn=E2=80=99t seen any official announcement<br>
> (unless I missed it) that indicated that they would no longer be creat=
ed.<br>
> <br>
> For any other folks using Red Hat =E2=80=93 what are you doing for dep=
loying OpenAFS?=C2=A0 Are there any repos out there equivalent to<br>
> the Ubuntu PPA?<br>
<br>
I've never managed to go from source tarball to clean RPMs. I found a w=
iki <br>
entry explaining how make a srpm, but it didn't work for me, at least f=
or <br>
recent releases.<br>
<br>
However, there is a wiki entry explaining how to build from a git <br>
checkout, and that worked once I had all the GNU autotools in place.=C2=A0 =
I'm <br>
sure this procedure does far more work than needed, but this is the brief <=
br>
summary of steps:<br>
<br>
$ cd ~/projects/openafs/1.8.2<br>
$ git clone git://<a href=3D"http://git.openafs.org/openafs.git" rel=3D"nor=
eferrer" target=3D"_blank">git.openafs.org/openafs.git</a><br>
$ cd openafs<br>
$ git checkout openafs-stable-1_8_2<br>
$ ./regen.sh<br>
$ ./configure --enable-transarc-paths --enable-checking --enable-supergroup=
s<br>
$ make dist<br>
$ make srpm<br>
$ rpmbuild --rebuild -ba --define "_topdir `pwd`/rpmbuild" --with=
kauth packages/openafs-1.8.2-1.src.rpm<br>
$ cd rpmbuild/x86_64/<br>
<br>
=C2=A0 =C2=A0- copy the resulting RPMs to local distribution point.<br>
<br>
This worked cleanly on RHEL6 and RHEL7<br>
<br>
Richard<br>
<br>
> Brian<br>
> <br>
> =C2=A0<br>
> <br>
> --<br>
> <br>
> Brian Sebby=C2=A0 (<a href=3D"mailto:sebby@anl.gov" target=3D"_blank">=
sebby@anl.gov</a>)=C2=A0 |=C2=A0 Information Technology Infrastructure<br>
> <br>
> Phone: +1 630.252.9935=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0 Business Information Services<br>
> <br>
> Cell:=C2=A0 +1 630.921.4305=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
|=C2=A0 Argonne National Laboratory<br>
> <br>
> =C2=A0<br>
> <br>
> =C2=A0<br>
> <br>
> From: <<a href=3D"mailto:openafs-info-admin@openafs.org" target=3D"=
_blank">openafs-info-admin@openafs.org</a>> on behalf of Benjamin Kaduk =
<<a href=3D"mailto:kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu</a>>=
;<br>
> Date: Tuesday, September 11, 2018 at 2:09 PM<br>
> To: <<a href=3D"mailto:openafs-announce@openafs.org" target=3D"_bla=
nk">openafs-announce@openafs.org</a>><br>
> Cc: <<a href=3D"mailto:openafs-devel@openafs.org" target=3D"_blank"=
>openafs-devel@openafs.org</a>>, <<a href=3D"mailto:openafs-info@open=
afs.org" target=3D"_blank">openafs-info@openafs.org</a>><br>
> Subject: [OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available<b=
r>
> <br>
> =C2=A0<br>
> <br>
> =C2=A0<br>
> <br>
> The OpenAFS Guardians are happy to announce the availability of<br>
> <br>
> Security Releases OpenAFS 1.8.2 and 1.6.23.<br>
> <br>
> Source files can be accessed via the web at:<br>
> <br>
> =C2=A0<br>
> <br>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <a href=3D"https://www.openafs.or=
g/release/openafs-1.8.2.html" rel=3D"noreferrer" target=3D"_blank">https://=
www.openafs.org/release/openafs-1.8.2.html</a><br>
> <br>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <a href=3D"https://www.openafs.or=
g/release/openafs-1.6.23.html" rel=3D"noreferrer" target=3D"_blank">https:/=
/www.openafs.org/release/openafs-1.6.23.html</a><br>
> <br>
> =C2=A0<br>
> <br>
> or via AFS at:<br>
> <br>
> =C2=A0<br>
> <br>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 UNIX: /afs/<a href=3D"http://gran=
d.central.org/software/openafs/1.8.2/" rel=3D"noreferrer" target=3D"_blank"=
>grand.central.org/software/openafs/1.8.2/</a><br>
> <br>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 UNC: \\afs\<a href=3D"http://gran=
d.central.org" rel=3D"noreferrer" target=3D"_blank">grand.central.org</a>\s=
oftware\openafs\1.8.2\<br>
> <br>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 UNIX: /afs/<a href=3D"http://gran=
d.central.org/software/openafs/1.6.23/" rel=3D"noreferrer" target=3D"_blank=
">grand.central.org/software/openafs/1.6.23/</a><br>
> <br>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 UNC: \\afs\<a href=3D"http://gran=
d.central.org" rel=3D"noreferrer" target=3D"_blank">grand.central.org</a>\s=
oftware\openafs\1.6.23\<br>
> <br>
> =C2=A0<br>
> <br>
> These releases include fixes for three security advisories,<br>
> <br>
> OPENAFS-SA-2018-001, OPENAFS-SA-2018-002, and OPENAFS-SA-2018-003.<br>
> <br>
> =C2=A0<br>
> <br>
> OPENAFS-SA-2018-001 only affects deployments that run the 'butc=
9; utility<br>
> <br>
> as part of the in-tree backup system, but is of high severity for<br>
> <br>
> those sites which are affected -- an anonymous attacker could replace<=
br>
> <br>
> entire volumes with attacker-controlled contents.<br>
> <br>
> =C2=A0<br>
> <br>
> OPENAFS-SA-2018-002 is for information leakage over the network via<br=
>
> <br>
> uninitialized RPC output variables.=C2=A0=C2=A0A number of RPCs are af=
fected,<br>
> <br>
> some of which require the caller to be authenticated, but in some case=
s<br>
> <br>
> hundreds of bytes of data can be leaked per call.=C2=A0=C2=A0Of note i=
s that<br>
> <br>
> cache managers are also subject to (kernel) memory leakage via<br>
> <br>
> AFSCB_ RPCs.<br>
> <br>
> =C2=A0<br>
> <br>
> OPENAFS-SA-2018-003 is a denial of service whereby anonymous attackers=
<br>
> <br>
> can cause server processes to consume large quantities of memory for<b=
r>
> <br>
> a sustained period of time.<br>
> <br>
> =C2=A0<br>
> <br>
> Please see the release notes and security advisories for additional de=
tails.<br>
> <br>
> =C2=A0<br>
> <br>
> The changes to fix OPENAFS-SA-2018-001 require behavior change in both=
<br>
> <br>
> butc(8) and backup(8) to use authenticated connections; old and new<br=
>
> <br>
> versions of these utilities will not interoperate absent specific<br>
> <br>
> configuration of the new tool to use the old (insecure) behavior.<br>
> <br>
> These changes also are expected to cause backup(8)'s interactive m=
ode<br>
> <br>
> to be limited to only butc connections requiring (or not requiring)<br=
>
> <br>
> authentication within a given interactive session, based on the initia=
l<br>
> <br>
> arguments selected.<br>
> <br>
> =C2=A0<br>
> <br>
> Bug reports should be filed to <a href=3D"mailto:openafs-bugs@openafs.=
org" target=3D"_blank">openafs-bugs@openafs.org</a>.<br>
> <br>
> =C2=A0<br>
> <br>
> Benjamin Kaduk<br>
> <br>
> for the OpenAFS Guardians<br>
> <br>
> =C2=A0<br>
> <br>
> <br>
><br>
<br>
-----<br>
Richard Brittain,=C2=A0 Research ITC<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Infor=
mation, Technology and Consulting,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 37 De=
wey Field Road, HB6219<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Dartm=
outh College, Hanover NH 03755<br>
<a href=3D"mailto:Richard.Brittain@dartmouth.edu" target=3D"_blank">Richard=
.Brittain@dartmouth.edu</a> 603-646-2085<br>
<a href=3D"http://rc.dartmouth.edu/" rel=3D"noreferrer" target=3D"_blank">h=
ttp://rc.dartmouth.edu/</a></blockquote></div></div>
--0000000000009d1f7d0578202dfe--