[OpenAFS] OpenAFS Security Releases 1.8.2, 1.6.23 available

[Benjamin Kaduk]

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' utility
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-***@openafs.org.

Benjamin Kaduk
for the OpenAFS Guardians

[Giovanni Bracco]

Hello everybody!

I have read about the butc & backup security update.

We run daily the AFS backup and I would like to understand if I need
just to update the backup server with the new butc/backup modules or I
need also to update all our file servers in order to match the new
security improvements connected to backup.

Giovanni

Post by Benjamin Kaduk
The OpenAFS Guardians are happy to announce the availability of
Security Releases OpenAFS 1.8.2 and 1.6.23.
https://www.openafs.org/release/openafs-1.8.2.html
https://www.openafs.org/release/openafs-1.6.23.html
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' utility
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.
Benjamin Kaduk
for the OpenAFS Guardians

[Mark Vitale]

Giovanni,

Post by Giovanni Bracco
I have read about the butc & backup security update.
We run daily the AFS backup and I would like to understand if I need just to update the backup server with the new butc/backup modules or I need also to update all our file servers in order to match the new security improvements connected to backup.

Your question seems to be mostly concerned with securing your backups,
so I'll answer that specific question first.
If we just consider the OpenAFS backup system in isolation,
I'm pretty sure you do not need to make changes to your fileservers
in order to pick up the butc security fixes. (Ben, please chime in if
you disagree).
I believe you only _need_ to update butc, but of course it's good
practice for all the backup system components to have the same version:
- butc
- backup (client)
- buserver

However, the other security fixes in this release do include updates
to non-backup OpenAFS components, including several volserver fixes (which
would require updating your fileservers). There are also important
client and DB server security fixes in this release.

Therefore, I think it's fine if you just update your backup components
for now. However, since some of these vulnerabilities are remotely
exploitable, I recommend updating the rest of your cell to the current
release as soon as you can manage it.

Regards,
--
Mark Vitale
OpenAFS release team

[Benjamin Kaduk]

Post by Mark Vitale
Giovanni,

Post by Giovanni Bracco
I have read about the butc & backup security update.
We run daily the AFS backup and I would like to understand if I need just to update the backup server with the new butc/backup modules or I need also to update all our file servers in order to match the new security improvements connected to backup.

Your question seems to be mostly concerned with securing your backups,
so I'll answer that specific question first.
If we just consider the OpenAFS backup system in isolation,
I'm pretty sure you do not need to make changes to your fileservers
in order to pick up the butc security fixes. (Ben, please chime in if
you disagree).
I believe you only _need_ to update butc, but of course it's good

You need an updated backup(8) to talk to the updated butc, but I think that
Giovanni had this in mind already.

-Ben

[Jeffrey Altman]

It is unfortunate that the announcement e-mail included neither a URL to
the https://www.openafs.org/security/ page nor a link to the individual
security advisory text files:

https://www.openafs.org/pages/security/OPENAFS-SA-2018-001.txt
https://www.openafs.org/pages/security/OPENAFS-SA-2018-002.txt
https://www.openafs.org/pages/security/OPENAFS-SA-2018-003.txt

In the case of OPENAFS-SA-2018-001.txt, both 'butc' and 'backup' (or
'afsbackup' as it is installed on some systems) must be at least:

* AuriStorFS v0.175
* OpenAFS 1.8.2
* OpenAFS 1.6.23

The version of the vlserver, buserver and volserver does not matter.
Those services already supported authenticated and potentially encrypted
connections.

The underlying cause of the incompatibility is that the 'butc' service
would only accept unauthenticated (rxnull) connections and therefore the
'backup' command could only create unauthenticated (rxnull) connections
even if the 'backup' command was executed with -localauth.

As of the releases above, the 'butc' service (by default) will not only
accept authenticated connections but will require that the authenticated
identity be a super-user as reported by the butc host's "bos listusers"
command.

There is no incompatibility with vlserver, buserver and volserver
because those services already accepted authenticated connections and
required that authenticated identities be super-users in order to
create, read, modify, or delete sensitive information.

The privilege escalation is due to 'butc' accepting unauthenticated
requests and executing them using a super-user identity when contacting
the vlserver, buserver, and volserver.

I cannot stress enough how important it is for sites that are running
the AFS backup suite to immediately:

. upgrade all instances of 'butc' and 'backup'.

. firewall the 'butc' ports from all machines except those from
which 'backup' is expected to be issued from. The butc port is
(7021 + butc port offset)/udp. The default offset is 0.

Otherwise, an anonymous attacker can read, alter or destroy the content
of any volume in the cell as well as any backups that do not require
manual intervention by a system administrator to gain access to.

AuriStor coordinated the release of these changes with the OpenAFS
Security officer(s) because this privilege escalation is not only
remotely exploitable but compromises the security and integrity of all
data stored within an AFS cell that operates a Backup Tape Controller
(butc) instance.

The AuriStorFS v0.175 release extends the AuriStorFS security model to
backup with the use of AES256-CTS-HMAC-SHA1-96 wire encryption for all
volume data communications and the use of volume security policies to
ensure that volumes cannot be restored to a fileserver with an
incompatible security policy.

Jeffrey Altman
AuriStor, Inc.

Post by Giovanni Bracco
Hello everybody!
I have read about the butc & backup security update.
We run daily the AFS backup and I would like to understand if I need
just to update the backup server with the new butc/backup modules or I
need also to update all our file servers in order to match the new
security improvements connected to backup.
Giovanni

Post by Benjamin Kaduk
OPENAFS-SA-2018-001 only affects deployments that run the 'butc' utility
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.
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.
Benjamin Kaduk
for the OpenAFS Guardians

[Mark Vitale]

<snip>
In the case of OPENAFS-SA-2018-001.txt, both 'butc' and 'backup' (or
* AuriStorFS v0.175
* OpenAFS 1.8.2
* OpenAFS 1.6.23
<snip>
As of the releases above, the 'butc' service (by default) will not only
accept authenticated connections but will require that the authenticated
identity be a super-user as reported by the butc host's "bos listusers"
command.

A small correction: the OpenAFS 'butc' does not do this by default.
Instead, it forces the operator to specify one of the following options:

-localauth
All butc RPCs require superuser authentication.
This option must be run as root, and server key material must be present.

-allow_unauthenticated
All butc RPCs remain unauthenticated.


Regards,
--
Mark Vitale
***@sinenomine.net

[Giovanni Bracco]

I have made some tests - ok it works - but I wonder why the key
autentication method is allowed only to root user

Post by Jeffrey Altman
-localauth
All butc RPCs require superuser authentication.
This option must be run as root, and server key material must be present.

Our backup scripts, which have been running on a dedicated server for
many years, run under a dedicated user with administrative powers.

Why the availability of a admin token is not sufficient to run butc in a
secure way?

Giovanni

Post by Jeffrey Altman

<snip>
In the case of OPENAFS-SA-2018-001.txt, both 'butc' and 'backup' (or
* AuriStorFS v0.175
* OpenAFS 1.8.2
* OpenAFS 1.6.23
<snip>
As of the releases above, the 'butc' service (by default) will not only
accept authenticated connections but will require that the authenticated
identity be a super-user as reported by the butc host's "bos listusers"
command.

A small correction: the OpenAFS 'butc' does not do this by default.
-localauth
All butc RPCs require superuser authentication.
This option must be run as root, and server key material must be present.
-allow_unauthenticated
All butc RPCs remain unauthenticated.
Regards,
--
Mark Vitale

[Jeffrey Altman]

Post by Giovanni Bracco
I have made some tests - ok it works - but I wonder why the key
autentication method is allowed only to root user

Post by Jeffrey Altman
-localauth
All butc RPCs require superuser authentication.
This option must be run as root, and server key material must be present.

Our backup scripts, which have been running on a dedicated server for
many years, run under a dedicated user with administrative powers.
Why the availability of a admin token is not sufficient to run butc in a
secure way?
Giovanni

A user token can be used to authenticate outgoing connections such as
those from butc to the buserver or the volserver. It cannot be used to
authenticate incoming connections to butc from the backup coordinator
command ("backup" or "afsbackup" depending upon the packaging.)

The privilege escalation attack is possible because of butc accepting
unauthenticated "anonymous" requests that would then result in RPCs
being issued as a privileged identity to the buserver and the volserver.
To close the security hole butc must authenticate all incoming RPCs.
To do so butc must have knowledge of the cell-wide key because without
knowledge of that key it cannot decrypt the AFS token presented by the
RPC issuer.

Jeffrey Altman

[Giovanni Bracco]

OK, I understand, thank you!
Giovanni

Post by Jeffrey Altman

Post by Giovanni Bracco
I have made some tests - ok it works - but I wonder why the key
autentication method is allowed only to root user

Post by Jeffrey Altman
-localauth
All butc RPCs require superuser authentication.
This option must be run as root, and server key material must be present.

Our backup scripts, which have been running on a dedicated server for
many years, run under a dedicated user with administrative powers.
Why the availability of a admin token is not sufficient to run butc in a
secure way?
Giovanni

A user token can be used to authenticate outgoing connections such as
those from butc to the buserver or the volserver. It cannot be used to
authenticate incoming connections to butc from the backup coordinator
command ("backup" or "afsbackup" depending upon the packaging.)
The privilege escalation attack is possible because of butc accepting
unauthenticated "anonymous" requests that would then result in RPCs
being issued as a privileged identity to the buserver and the volserver.
To close the security hole butc must authenticate all incoming RPCs.
To do so butc must have knowledge of the cell-wide key because without
knowledge of that key it cannot decrypt the AFS token presented by the
RPC issuer.
Jeffrey Altman

[Thomas Otto]

Hello,

my backup via butc is broken and I am not able to get an actual butc binary
for Solaris 10 sparc (sun4x_510).
The last binary to download is 1.6.10 and my tries to compile the source of 1.6.23
all fails or the result isn't valid (core dumps) :(

Is there anyone who can send me the 1.6.23 butc binary for Solaris 10 on sparc?


My binary is significant less then the others
-rwxr-xr-x 1 root root 987288 Oct 17 13:28 butc-1.6.23
-rwxr-xr-x 1 root root 2819684 Oct 15 2014 butc-1.6.10
-rwxr-xr-x 1 root root 2808324 Apr 10 2014 butc-1.6.7

And core dumps ...

bash-3.2# /usr/afs/backup/butc -port 0 -debuglevel 2 -localauth
Will dump to a file
Tape mount callout routine is /usr/afs/backup/mount-afs-backup-file.sh
Warning: Unrecognized configuration parameter: UMOUNT /usr/afs/backup/mount-afs-backup-file.sh
Operator queries are disabled
Segmentation Fault (core dumped)


Best regards

Thomas Otto

Post by Jeffrey Altman
It is unfortunate that the announcement e-mail included neither a URL to
the https://www.openafs.org/security/ page nor a link to the individual
https://www.openafs.org/pages/security/OPENAFS-SA-2018-001.txt
https://www.openafs.org/pages/security/OPENAFS-SA-2018-002.txt
https://www.openafs.org/pages/security/OPENAFS-SA-2018-003.txt
In the case of OPENAFS-SA-2018-001.txt, both 'butc' and 'backup' (or
* AuriStorFS v0.175
* OpenAFS 1.8.2
* OpenAFS 1.6.23
The version of the vlserver, buserver and volserver does not matter.
Those services already supported authenticated and potentially encrypted
connections.
The underlying cause of the incompatibility is that the 'butc' service
would only accept unauthenticated (rxnull) connections and therefore the
'backup' command could only create unauthenticated (rxnull) connections
even if the 'backup' command was executed with -localauth.
As of the releases above, the 'butc' service (by default) will not only
accept authenticated connections but will require that the authenticated
identity be a super-user as reported by the butc host's "bos listusers"
command.
There is no incompatibility with vlserver, buserver and volserver
because those services already accepted authenticated connections and
required that authenticated identities be super-users in order to
create, read, modify, or delete sensitive information.
The privilege escalation is due to 'butc' accepting unauthenticated
requests and executing them using a super-user identity when contacting
the vlserver, buserver, and volserver.
I cannot stress enough how important it is for sites that are running
. upgrade all instances of 'butc' and 'backup'.
. firewall the 'butc' ports from all machines except those from
which 'backup' is expected to be issued from. The butc port is
(7021 + butc port offset)/udp. The default offset is 0.
Otherwise, an anonymous attacker can read, alter or destroy the content
of any volume in the cell as well as any backups that do not require
manual intervention by a system administrator to gain access to.
AuriStor coordinated the release of these changes with the OpenAFS
Security officer(s) because this privilege escalation is not only
remotely exploitable but compromises the security and integrity of all
data stored within an AFS cell that operates a Backup Tape Controller
(butc) instance.
The AuriStorFS v0.175 release extends the AuriStorFS security model to
backup with the use of AES256-CTS-HMAC-SHA1-96 wire encryption for all
volume data communications and the use of volume security policies to
ensure that volumes cannot be restored to a fileserver with an
incompatible security policy.
Jeffrey Altman
AuriStor, Inc.

Post by Giovanni Bracco
Hello everybody!
I have read about the butc & backup security update.
We run daily the AFS backup and I would like to understand if I need
just to update the backup server with the new butc/backup modules or I
need also to update all our file servers in order to match the new
security improvements connected to backup.
Giovanni

Post by Benjamin Kaduk
OPENAFS-SA-2018-001 only affects deployments that run the 'butc' utility
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.
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.
Benjamin Kaduk
for the OpenAFS Guardians

[Sebby, Brian A.]

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’t 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’s been discussed for a long time, but I hadn’t seen any official announcement (unless I missed it) that indicated that they would no longer be created.

For any other folks using Red Hat – what are you doing for deploying OpenAFS? Are there any repos out there equivalent to the Ubuntu PPA?


Brian
--
Brian Sebby (***@anl.gov) | Information Technology Infrastructure
Phone: [phone] | Business Information Services
Cell: +1 630.921.4305 | Argonne National Laboratory


From: <openafs-info-***@openafs.org> on behalf of Benjamin Kaduk <***@mit.edu>
Date: Tuesday, September 11, 2018 at 2:09 PM
To: <openafs-***@openafs.org>
Cc: <openafs-***@openafs.org>, <openafs-***@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' utility
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-***@openafs.org<mailto:openafs-***@openafs.org>.

Benjamin Kaduk
for the OpenAFS Guardians

[Dave Botsch]

Uusually I grab the .src.rpm , rebuild it, and then push the generated
binaries to our machines.

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’t 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’s been discussed for a long time, but I hadn’t seen any official announcement (unless I missed it) that indicated that they would no longer be created.
For any other folks using Red Hat – what are you doing for deploying OpenAFS? Are there any repos out there equivalent to the Ubuntu PPA?
Brian
--
Phone: [phone] | Business Information Services
Cell: +1 630.921.4305 | Argonne National Laboratory
Date: Tuesday, September 11, 2018 at 2:09 PM
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.
https://www.openafs.org/release/openafs-1.8.2.html
https://www.openafs.org/release/openafs-1.6.23.html
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' utility
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.
Benjamin Kaduk
for the OpenAFS Guardians

[Richard Brittain]

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’t 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’s been discussed for a long time, but I hadn’t seen any official announcement
(unless I missed it) that indicated that they would no longer be created.
For any other folks using Red Hat – what are you doing for deploying 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 wiki
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
 
--
Phone: [phone]        |  Business Information Services
Cell:  +1 630.921.4305        |  Argonne National Laboratory
 
 
Date: Tuesday, September 11, 2018 at 2:09 PM
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.
 
       https://www.openafs.org/release/openafs-1.8.2.html
       https://www.openafs.org/release/openafs-1.6.23.html
 
 
       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' utility
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.
 
 
Benjamin Kaduk
for the OpenAFS Guardians
 

-----
Richard Brittain, Research ITC
Information, Technology and Consulting,
37 Dewey Field Road, HB6219
Dartmouth College, Hanover NH 03755
***@dartmouth.edu 603-646-2085
http://rc.dartmouth.edu/���(�~���X��X���^�
R�w袗�i�(�

[Matt Vander Werf]

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.
--
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 <

Post by Sebby, Brian A.

Post by Sebby, Brian A.
Previous releases have included source RPMs that made it easier for us

to build RPMs to deploy to our Red Hat-based servers.

Post by Sebby, Brian A.
I was hoping it maybe had just not yet been released yet, but there

still isn’t a source RPM for 1.6.23. It looks like one

Post by Sebby, Brian A.
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

Post by Sebby, Brian A.
support for RPMs from OpenAFS is something that’s been discussed for a

long time, but I hadn’t seen any official announcement

Post by Sebby, Brian A.
(unless I missed it) that indicated that they would no longer be created.
For any other folks using Red Hat – what are you doing for deploying

OpenAFS? Are there any repos out there equivalent to

Post by Sebby, Brian A.
the Ubuntu PPA?

I've never managed to go from source tarball to clean RPMs. I found a wiki
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
$ 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

Post by Sebby, Brian A.
Brian
--
Phone: [phone] | Business Information Services
Cell: +1 630.921.4305 | Argonne National Laboratory
Date: Tuesday, September 11, 2018 at 2:09 PM
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.
https://www.openafs.org/release/openafs-1.8.2.html
https://www.openafs.org/release/openafs-1.6.23.html
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' utility
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.

Post by Sebby, Brian A.
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.
Benjamin Kaduk
for the OpenAFS Guardians

-----
Richard Brittain, Research ITC
Information, Technology and Consulting,
37 Dewey Field Road, HB6219
Dartmouth College, Hanover NH 03755
http://rc.dartmouth.edu/

[Benjamin Kaduk]

Post by Matt Vander Werf
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).

You're exactly right; I don't have any RPM systems and had to do those
releases under embargo.

Post by Matt Vander Werf
If the SRPM doesn't get put out with the release, we essentially follow the
instructions Richard sent, with a couple minor differences.
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).

I'll re-post the instructions I've gotten for how to generate an SRPM from
scratch:

tar xf openafs-1.8.0-src.tar.bz2 openafs-1.8.0/src/packaging/RedHat
./openafs-1.8.0/src/packaging/RedHat/makesrpm.pl openafs-1.8.0-src.tar.bz2
openafs-1.8.0-doc.tar.bz2 RELNOTES-1.8.0 ChangeLog

This should be either done on a system with an old rpm or with the
following in ~/.rpmmacros:

# build EL5 compatible SRPMs:
%_source_filedigest_algorithm md5


An enterprising soul might find a good place for that in the wiki (ideally,
after verifying that it still works).

Thanks,

Ben

[Glick, Bill]

Richard’s approach is very similar to how I’ve been building openafs RPMs recently.

Historically I used RPMs from the CentOS Storage SIG, but they haven’t officially supported OpenAFS and aren’t keeping up to date.

Currently I’m trying to leverage Fedora’s COPR system to build and maintain openafs RPMs with the approach Richard (different approach to how Jonathan Billings is using COPR). I was actually working on this the last few days and am getting very close. I’m currently stuck at figuring out how to auto generate a SPEC file to pass COPR along with the generated SRPM. The COPR system appears to want to use a SPEC file to generate the binary RPMs from the SRPM. I haven’t been able to figure out how to generate a functional SPEC file using make against openafs src.

--
Bill Glick
Sr System Engineer - NCSA - University of Illinois at Urbana-Champaign

Post by Richard Brittain

Post by Sebby, Brian A.
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’t 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’s been discussed for a long time, but I hadn’t seen any official announcement
(unless I missed it) that indicated that they would no longer be created.
For any other folks using Red Hat – what are you doing for deploying 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 wiki
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
$ 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

Post by Sebby, Brian A.
Brian
--
Phone: [phone] | Business Information Services
Cell: +1 630.921.4305 | Argonne National Laboratory
Date: Tuesday, September 11, 2018 at 2:09 PM
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.
https://www.openafs.org/release/openafs-1.8.2.html
https://www.openafs.org/release/openafs-1.6.23.html
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' utility
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.
Benjamin Kaduk
for the OpenAFS Guardians

-----
Richard Brittain, Research ITC
Information, Technology and Consulting,
37 Dewey Field Road, HB6219
Dartmouth College, Hanover NH 03755
http://rc.dartmouth.edu/���(�~���X��X���^�
R�w袗�i�(�m��?�X���)zv�����f��f��X��)ߣ�)zv��)

�zpJ)ߢf��)��+-:��T���(���~�+

[Benjamin Kaduk]

Post by Glick, Bill
Richard’s approach is very similar to how I’ve been building openafs RPMs recently.
Historically I used RPMs from the CentOS Storage SIG, but they haven’t officially supported OpenAFS and aren’t keeping up to date.
Currently I’m trying to leverage Fedora’s COPR system to build and maintain openafs RPMs with the approach Richard (different approach to how Jonathan Billings is using COPR). I was actually working on this the last few days and am getting very close. I’m currently stuck at figuring out how to auto generate a SPEC file to pass COPR along with the generated SRPM. The COPR system appears to want to use a SPEC file to generate the binary RPMs from the SRPM. I haven’t been able to figure out how to generate a functional SPEC file using make against openafs src.

The src/packaging/RedHat/makesrpm.pl script I mentioned in
https://lists.openafs.org/pipermail/openafs-info/2018-October/042567.html
produces a spec file as an intermediate step; I would expect that that
script (or something similar) would be suitable for your purposes.

-Ben

[Andreas Ladanyi]

Hi Brian,

Post by Sebby, Brian A.
For any other folks using Red Hat – what are you doing for deploying
OpenAFS?  Are there any repos out there equivalent to the Ubuntu PPA?

https://copr.fedorainfracloud.org/coprs/jsbillings/openafs/packages/

regards,
Andy