Debian Bug report logs - #889098
enforce fs.protected_hardlinks in sysctl.d by default

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Date: Thu, 01 Feb 2018 17:05:51 -0500

Package: procps
Version: 2:3.3.12-3
Severity: normal
Tags: security

Following the disclosure of CVE-2017-18078, there was an elaborate
discussion on the #debian-devel and #debian-security IRC channels
regarding the scope of the vulnerability. It was then realized that
the impact of this was broader than just systemd: any time a command
like `chown -R` is ran over an untrusted directory, by root, the same
problem occurs.

This is of course mitigated by the fs.protected_hardlinks kernel
configuration, which is enforced through a patch on all the official
Debian kernels distributed by Debian, including in wheezy. See for
example:

    https://sources.debian.org/src/linux/3.16.7-ckt20-1+deb8u3/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/
    https://sources.debian.org/src/linux/4.14.13-1/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/

There are, however, people *not* running Debian-built kernels, and
sometimes for good reasons. This is a configuration that we should
still support.

Therefore, it seems to me we should enable this more broadly, for
example in /etc/sysctl.d/protected-hardlinks.conf. Configuring this in
user space is actually what is recommended by Linus Torvalds and the
upstream Linux kernel:

    https://github.com/torvalds/linux/commit/561ec64ae67ef25cac8d72bb9c4bfc955edfd415

systemd ships this configuration as well, but this was deliberately
removed from Debian's systemd configuration:

    https://salsa.debian.org/systemd-team/systemd/commit/3e1bfe0d84545557d268c1293fff0d5f3db3b5c7

I agree with the above perspective: systemd is not sufficient to
resolve that issue. We still have other init systems and we shouldn't
fix this in systemd, but in a broader package. This is why I am
proposing to fix this in procps, which ultimately owns /etc/sysctl.d/
(and /etc/sysctl.conf).

This is not a strong position: if people think this belongs in systemd
more than procps, or there is some more relevant place this can be
done *by default*, let's do it there and not quibble over that
peculiar bikeshed. :)

I would suggest adding the following configuration:

# Enable hard link protection
fs.protected_hardlinks = 1

Note that the original systemd config also enables softlink
protection:

https://salsa.debian.org/systemd-team/systemd/blob/master/sysctl.d/50-default.conf

I'm not sure if that's also relevant here so I'd keep this to
hardlinks for now to avoid unnecessary debate.

Incidentally, I wonder if we should remove the patch we have on the
Debian kernels to change the defaults, and instead rely on the
sysctl. I have added the kernel team in CC to have their input.

Thanks!

Message #10 received at 889098@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: 889098@bugs.debian.org

Cc: Debian Security Team <team@security.debian.org>, Debian Testing Security Team <secure-testing-team@lists.alioth.debian.org>, debian-kernel@lists.debian.org

Subject: enforce fs.protected_hardlinks in sysctl.d by default

Date: Thu, 01 Feb 2018 17:15:03 -0500

Control: retitle 889098 enforce fs.protected_hardlinks in sysctl.d by default

Package: procps
Version: 2:3.3.12-3
Severity: normal
Tags: security

Following the disclosure of CVE-2017-18078, there was an elaborate
discussion on the #debian-devel and #debian-security IRC channels
regarding the scope of the vulnerability. It was then realized that
the impact of this was broader than just systemd: any time a command
like `chown -R` is ran over an untrusted directory, by root, the same
problem occurs.

This is of course mitigated by the fs.protected_hardlinks kernel
configuration, which is enforced through a patch on all the official
Debian kernels distributed by Debian, including in wheezy. See for
example:

https://sources.debian.org/src/linux/3.16.7-ckt20-1+deb8u3/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/
https://sources.debian.org/src/linux/4.14.13-1/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/

There are, however, people *not* running Debian-built kernels, and
sometimes for good reasons. This is a configuration that we should
still support.

Therefore, it seems to me we should enable this more broadly, for
example in /etc/sysctl.d/protected-hardlinks.conf. Configuring this in
user space is actually what is recommended by Linus Torvalds and the
upstream Linux kernel:

https://github.com/torvalds/linux/commit/561ec64ae67ef25cac8d72bb9c4bfc955edfd415

systemd ships this configuration as well, but this was deliberately
removed from Debian's systemd configuration:

https://salsa.debian.org/systemd-team/systemd/commit/3e1bfe0d84545557d268c1293fff0d5f3db3b5c7

I agree with the above perspective: systemd is not sufficient to
resolve that issue. We still have other init systems and we shouldn't
fix this in systemd, but in a broader package. This is why I am
proposing to fix this in procps, which ultimately owns /etc/sysctl.d/
(and /etc/sysctl.conf).

This is not a strong position: if people think this belongs in systemd
more than procps, or there is some more relevant place this can be
done *by default*, let's do it there and not quibble over that
peculiar bikeshed. :)

I would suggest adding the following configuration:

# Enable hard link protection
fs.protected_hardlinks = 1

Note that the original systemd config also enables softlink
protection:

https://salsa.debian.org/systemd-team/systemd/blob/master/sysctl.d/50-default.conf

I'm not sure if that's also relevant here so I'd keep this to
hardlinks for now to avoid unnecessary debate.

Incidentally, I wonder if we should remove the patch we have on the
Debian kernels to change the defaults, and instead rely on the
sysctl. I have added the kernel team in CC to have their input.

Thanks!

PS: sorry for the duplicate email, I had a copy-paste problem with
reportbug and forgot to re-set a subject.

-- 
We don't need any more heroes.
We just need someone to take out recycling.
                        - Banksy

Message #17 received at 889098@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Antoine Beaupre <anarcat@debian.org>, 889098@bugs.debian.org

Subject: Re: Bug#889098: enforce fs.protected_hardlinks in sysctl.d by default

Date: Fri, 02 Feb 2018 02:30:39 +0000

[Message part 1 (text/plain, inline)]

On Thu, 2018-02-01 at 17:05 -0500, Antoine Beaupre wrote:
[...]
> Note that the original systemd config also enables softlink
> protection:
> 
> https://salsa.debian.org/systemd-team/systemd/blob/master/sysctl.d/50-default.conf
>
> I'm not sure if that's also relevant here so I'd keep this to
> hardlinks for now to avoid unnecessary debate.
> 
> Incidentally, I wonder if we should remove the patch we have on the
> Debian kernels to change the defaults, and instead rely on the
> sysctl. I have added the kernel team in CC to have their input.

I would rather have the secure default specified in both places.  If we
unpatch the kernel then there's a risk of re-enabling link attacks in a
partial upgrade or backporting.

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 889098@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: 889098@bugs.debian.org, Debian Security Team <team@security.debian.org>, debian-kernel@lists.debian.org

Subject: Re: enforce fs.protected_hardlinks in sysctl.d by default

Date: Fri, 2 Feb 2018 21:25:31 +0100

Antoine Beaupré wrote:
> There are, however, people *not* running Debian-built kernels, and
> sometimes for good reasons. This is a configuration that we should
> still support.

Is it supported, but it's also clearly documented that people need to
enable this sysctl for custom kernels:
https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html#security

> Incidentally, I wonder if we should remove the patch we have on the
> Debian kernels to change the defaults, and instead rely on the
> sysctl. I have added the kernel team in CC to have their input.

Why revert the kernel? That doesn't buy us anything. It would be
better to ask upstream to revisit this decision (e.g. by contacting
KSPP mailing list). I suppose that SuSE, Ubuntu and Red Hat have
are shipping similar patches/defaults, so it's probably safe to say
that those protections are now the status quo (as opposed to five
years ago when that feature was freshly introduced).

Cheers,
        Moritz

Message #27 received at 889098@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Moritz Mühlenhoff <jmm@inutil.org>

Cc: 889098@bugs.debian.org, Debian Security Team <team@security.debian.org>, debian-kernel@lists.debian.org

Subject: Re: enforce fs.protected_hardlinks in sysctl.d by default

Date: Fri, 02 Feb 2018 17:23:51 -0500

On 2018-02-02 21:25:31, Moritz Mühlenhoff wrote:
> Antoine Beaupré wrote:
>> There are, however, people *not* running Debian-built kernels, and
>> sometimes for good reasons. This is a configuration that we should
>> still support.
>
> Is it supported, but it's also clearly documented that people need to
> enable this sysctl for custom kernels:
> https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html#security

True. I guess what I'm arguing for is to do this explicitly from here
on.

>> Incidentally, I wonder if we should remove the patch we have on the
>> Debian kernels to change the defaults, and instead rely on the
>> sysctl. I have added the kernel team in CC to have their input.
>
> Why revert the kernel? That doesn't buy us anything. It would be
> better to ask upstream to revisit this decision (e.g. by contacting
> KSPP mailing list). I suppose that SuSE, Ubuntu and Red Hat have
> are shipping similar patches/defaults, so it's probably safe to say
> that those protections are now the status quo (as opposed to five
> years ago when that feature was freshly introduced).

It was just an idea: I'm fine with keeping the patch and I think it's a
good idea to enforce this in two places, to keep defense in depth.

I'm not sure I want to go through the emotional trauma of trying to
bring this upstream, unfortunately. ;)

Thanks for the response.

A.

-- 
All governments are run by liars and nothing they say should be
believed.
                       - I. F. Stone

Message #32 received at 889098@bugs.debian.org (full text, mbox, reply):

From: Craig Small <csmall@debian.org>

To: Antoine Beaupré <anarcat@debian.org>, 889098@bugs.debian.org

Cc: Debian Security Team <team@security.debian.org>, Moritz Muehlenhoff <jmm@inutil.org>, debian-kernel@lists.debian.org

Subject: Re: Bug#889098: enforce fs.protected_hardlinks in sysctl.d by default

Date: Sat, 03 Feb 2018 00:45:46 +0000

[Message part 1 (text/plain, inline)]

Hi Antoine (and kernel and security teams),
  Thanks for giving me the background as it's a kernel vulnerability not a
Procps one I wasn't aware of it.

The change to Procps is pretty simple but given that you need to be running
a non Debian kernel without this parameter what's groups' opinion of the
urgency?

I can throw in the sysctl configuration file and upload a release this
weekend if the consensus is it's needed or wait for the next upstream
Procps release which would be a month or so away.

 - Craig

>
>
>

-- 
Craig Small             https://dropbear.xyz/     csmall at : dropbear.xyz
Debian GNU/Linux        https://www.debian.org/   csmall at : debian.org
Mastodon: @smallsees@social.dropbear.xyz             Twitter: @smallsees
GPG fingerprint:      5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

[Message part 2 (text/html, inline)]

Message #37 received at 889098@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Moritz Mühlenhoff <jmm@inutil.org>, 889098@bugs.debian.org

Cc: Antoine Beaupré <anarcat@debian.org>, Debian Security Team <team@security.debian.org>, debian-kernel@lists.debian.org

Subject: Re: Bug#889098: enforce fs.protected_hardlinks in sysctl.d by default

Date: Sat, 3 Feb 2018 10:54:18 +0100

Hi

On Fri, Feb 02, 2018 at 09:25:31PM +0100, Moritz Mühlenhoff wrote:
> Antoine Beaupré wrote:
> > There are, however, people *not* running Debian-built kernels, and
> > sometimes for good reasons. This is a configuration that we should
> > still support.
> 
> Is it supported, but it's also clearly documented that people need to
> enable this sysctl for custom kernels:
> https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html#security

Just to add a note: if procps is as well going to ship this hardening
for fs.protected_hardlinks then I think it would be best to follow the
kernel and do the same for fs.protected_symlinks as well, not only
the fs.protected_hardlinks.

> > Incidentally, I wonder if we should remove the patch we have on the
> > Debian kernels to change the defaults, and instead rely on the
> > sysctl. I have added the kernel team in CC to have their input.
> 
> Why revert the kernel? That doesn't buy us anything. It would be
> better to ask upstream to revisit this decision (e.g. by contacting
> KSPP mailing list). I suppose that SuSE, Ubuntu and Red Hat have
> are shipping similar patches/defaults, so it's probably safe to say
> that those protections are now the status quo (as opposed to five
> years ago when that feature was freshly introduced).

Agreed with you and Ben to actually not revert the sane defaults in
the Debian kernel.

Btw, upstream did initially as well set those, then reverted due to
some userspace programms breaking, they are/were rare, but the rule is
to not break userspace (this was done in the referenced commit, "VFS:
don't do protected {sym,hard}links by default", where it's noted that
it e.g. broke AFD.) 

Regards,
Salvatore

Message #42 received at 889098@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Craig Small <csmall@debian.org>, Antoine Beaupré <anarcat@debian.org>, 889098@bugs.debian.org

Cc: Debian Security Team <team@security.debian.org>, Moritz Muehlenhoff <jmm@inutil.org>, debian-kernel@lists.debian.org

Subject: Re: Bug#889098: enforce fs.protected_hardlinks in sysctl.d by default

Date: Sat, 03 Feb 2018 14:08:37 +0100

[Message part 1 (text/plain, inline)]

On Sat, 2018-02-03 at 00:45 +0000, Craig Small wrote:
> Hi Antoine (and kernel and security teams),
>   Thanks for giving me the background as it's a kernel vulnerability not a
> Procps one I wasn't aware of it.

It's not a kernel vulnerability, but a class of application
vulnerabilities that the kernel can protect against.

Ben.

> The change to Procps is pretty simple but given that you need to be running
> a non Debian kernel without this parameter what's groups' opinion of the
> urgency?
> 
> I can throw in the sysctl configuration file and upload a release this
> weekend if the consensus is it's needed or wait for the next upstream
> Procps release which would be a month or so away.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug

[signature.asc (application/pgp-signature, inline)]

Message #47 received at 889098@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Salvatore Bonaccorso <carnil@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>, 889098@bugs.debian.org

Cc: Debian Security Team <team@security.debian.org>, debian-kernel@lists.debian.org

Subject: Re: Bug#889098: enforce fs.protected_hardlinks in sysctl.d by default

Date: Sat, 03 Feb 2018 09:43:50 -0500

On 2018-02-03 10:54:18, Salvatore Bonaccorso wrote:
> Hi
>
> On Fri, Feb 02, 2018 at 09:25:31PM +0100, Moritz Mühlenhoff wrote:
>> Antoine Beaupré wrote:
>> > There are, however, people *not* running Debian-built kernels, and
>> > sometimes for good reasons. This is a configuration that we should
>> > still support.
>> 
>> Is it supported, but it's also clearly documented that people need to
>> enable this sysctl for custom kernels:
>> https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html#security
>
> Just to add a note: if procps is as well going to ship this hardening
> for fs.protected_hardlinks then I think it would be best to follow the
> kernel and do the same for fs.protected_symlinks as well, not only
> the fs.protected_hardlinks.

Agreed.

>> > Incidentally, I wonder if we should remove the patch we have on the
>> > Debian kernels to change the defaults, and instead rely on the
>> > sysctl. I have added the kernel team in CC to have their input.
>> 
>> Why revert the kernel? That doesn't buy us anything. It would be
>> better to ask upstream to revisit this decision (e.g. by contacting
>> KSPP mailing list). I suppose that SuSE, Ubuntu and Red Hat have
>> are shipping similar patches/defaults, so it's probably safe to say
>> that those protections are now the status quo (as opposed to five
>> years ago when that feature was freshly introduced).
>
> Agreed with you and Ben to actually not revert the sane defaults in
> the Debian kernel.
>
> Btw, upstream did initially as well set those, then reverted due to
> some userspace programms breaking, they are/were rare, but the rule is
> to not break userspace (this was done in the referenced commit, "VFS:
> don't do protected {sym,hard}links by default", where it's noted that
> it e.g. broke AFD.) 

Right. But we've been running with this as default in Debian for a
while. We also have good mechanisms (config file tracking) to allow
custom changes for users that build their own kernels, although that
might need a release notes update or something because that won't be
flagged by those mechanisms.

A.

-- 
Drowning people
Sometimes die
Fighting their rescuers.
                        - Octavia Butler

Message #52 received at 889098-close@bugs.debian.org (full text, mbox, reply):

From: Craig Small <csmall@debian.org>

To: 889098-close@bugs.debian.org

Subject: Bug#889098: fixed in procps 2:3.3.12-4

Date: Sat, 10 Feb 2018 03:35:37 +0000

Source: procps
Source-Version: 2:3.3.12-4

We believe that the bug you reported is fixed in the latest version of
procps, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 889098@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Craig Small <csmall@debian.org> (supplier of updated procps package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sat, 10 Feb 2018 10:59:11 +1100
Source: procps
Binary: procps libprocps6 libprocps-dev
Architecture: source amd64
Version: 2:3.3.12-4
Distribution: unstable
Urgency: medium
Maintainer: Craig Small <csmall@debian.org>
Changed-By: Craig Small <csmall@debian.org>
Description:
 libprocps-dev - library for accessing process information from /proc
 libprocps6 - library for accessing process information from /proc
 procps     - /proc file system utilities
Closes: 882121 889098
Changes:
 procps (2:3.3.12-4) unstable; urgency=medium
 .
   * Add sysctl configuration file to protect hard and soft links
     This mitigates CVE-2017-18078 on non-Debian kernels Closes: #889098
   * Update Vcs to Salsa
   * Update notes about sysrq Closes: #882121
   * Update standards to 4.1.3
Checksums-Sha1:
 1b7e53ba40ad9a1c6568b116a94b9b39348e783a 2127 procps_3.3.12-4.dsc
 317a46d0602f0c9fc1d2fb3532078d0bca887fba 27988 procps_3.3.12-4.debian.tar.xz
 36590d4bd6f0afa1b53bf598bfb5ed0482171b78 70172 libprocps-dev_3.3.12-4_amd64.deb
 14e33a52ce4e0f070e529ec39946edf8f39565ac 74028 libprocps6-dbgsym_3.3.12-4_amd64.deb
 998080d419a38999da571ee5a2813a3814c51ca3 58460 libprocps6_3.3.12-4_amd64.deb
 56ad3d5d8d771a58469c0505530df0c8c062e7fc 350696 procps-dbgsym_3.3.12-4_amd64.deb
 8e1a86603670011732a21324e221e12f1778f00a 6847 procps_3.3.12-4_amd64.buildinfo
 a09c43e4c343cc040ff8ffc970868439d099aaa8 251160 procps_3.3.12-4_amd64.deb
Checksums-Sha256:
 0e643e0ef86d77bd0465cebb0c8f66ffaf9ade1f7a34603242bacc2a25c8b359 2127 procps_3.3.12-4.dsc
 1fc7c5bb257f9123e759b751d400f761b6d248bfe9be6623f01d9afd6c328440 27988 procps_3.3.12-4.debian.tar.xz
 dafe60a7d7b0ee22ff7873d64c20271fda212352b0cfcc8b9785aefd091466c8 70172 libprocps-dev_3.3.12-4_amd64.deb
 60583bcc5d43fc398b74b9fe886d3f4cbc86624d0f2bbfdac20afd209850524d 74028 libprocps6-dbgsym_3.3.12-4_amd64.deb
 b4e0d19eff18e097f54c572cc4c3ea8b50ccdf22a9bc29bd0f6c66057a4b3aee 58460 libprocps6_3.3.12-4_amd64.deb
 c36fd8b2205e14e49023b3e36c959ff6b8e760d9ccc8e0a9c257ca9bab252f07 350696 procps-dbgsym_3.3.12-4_amd64.deb
 06beb6fa8c890909c16b6a3af536d195f5762217fd12b283e0fc9173d91f9e82 6847 procps_3.3.12-4_amd64.buildinfo
 9281285cd8e27174032919e2c195fdea558f28a62b1f9305fd7050d1433bce0d 251160 procps_3.3.12-4_amd64.deb
Files:
 335164e6890e7e070280f30854a7a392 2127 admin optional procps_3.3.12-4.dsc
 38d668f2849632beee910b8c51be8943 27988 admin optional procps_3.3.12-4.debian.tar.xz
 ce4daf33ce87e34479ae9bd30161ff60 70172 libdevel optional libprocps-dev_3.3.12-4_amd64.deb
 1106f0b99e79a0723c69d1a7faa48192 74028 debug optional libprocps6-dbgsym_3.3.12-4_amd64.deb
 341ecf395585fca3018ed4a8a8120721 58460 libs optional libprocps6_3.3.12-4_amd64.deb
 c61577b2d1d47606194d0300d37cfbe1 350696 debug optional procps-dbgsym_3.3.12-4_amd64.deb
 4d24047326eac803bf4c84d4610880c1 6847 admin optional procps_3.3.12-4_amd64.buildinfo
 357ef743bf0ebbbc8a5d025fa9e1e2c0 251160 admin important procps_3.3.12-4_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEXT3w9TizJ8CqeneiAiFmwP88hOMFAlp+YasACgkQAiFmwP88
hOOrkg/9HQ9UZI+feo1YwqPKthuTjwOgVViTyWrVZZgQh30Y06aQVl+valq/umzZ
U/x4x2QG4gGSbEzzWvhNjhj/bQ3fNIPItF0mDab8goErfcq2Xr+eZKjfSNrTh+C8
cpual0vd1yDv74ys6JTP3DxiGiackfSCSwclvOFF+Iq91YHCA1nCs7ZNbjQ56ikB
yQ0d/+9ySMPWzlOAMTE7AM8oIgIcN6Rl44UGnoGTQet5x0y92BVM0Xi1Cb0vo0fO
4pbluqe+YHAbtGzDB9QpVkmAsWqoHOpCF25hbSC7jfXXFkU85Iu3fzXptlfmES7R
Hl9uz5rrhq0jBXAxm9t3hMX71zuFF6lukA+vJ2YCgDqh1v49aUbd5187hCFtvmsq
DQda1K0jSrKUqKCqznca+NZskj6ZfgVIb7Ls/oRDnUGTt+mt9LMMO09V2VJWTzz1
gpFv/1cyz3Etw0wRKwoeGbDdSmmIm3O1paJF0mINhfagP8hTbZULqkNNzRFkehm/
0gbfHz44IRDLaqcWYx7/6yxYJfky9km65r344GW5UGrgIeOax+ONiXAIUCO7mvvC
Y1+R3htWNmGfxGDetWhAlv9DdyEoSvlWU4l3HTjtMu0E1KIB9I8R9Wz4PbqVat69
7ykQTokfLWA6YV32enFyf30SE6jdGcmZ0x/c2wkgWCbZx+R4Zxs=
=BeTS
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.