[arch-devops] security@archlinux.org address

older
[arch-devops] planet.archlinux.org...

Jelle van der Waa

11 Feb 2019 11 Feb '19

8:35 p.m.

For security@archlinux.org the Security Team wants to setup a way for reporters to securely mail encrypted issues to our email address. To limit the bus factor we want to send those emails to multiple receivers and then handle and/or forward the information appropriately. Schleuder providers an solution to this issue by decryping the sent email and re-encrypting it to the Arch Security team members. Since this requires a GPG key to be on the server, we want to implement this securely and hook up a nitrokey pro 2 to a separate Hetzner dedicated server. This server serves the sole purpose of hosting the security mail address. Installing by Hetzner costs 18 euro’s (excl. VAT). Options: * Cheapest Hetzner server 34 euro / month and 40 euro setup fees. * Hetzner auction server ~ 25 / month and no setup fees. * Different dedicated server hoster which allows custom usb devices. Benefits: * Key can’t be recovered by an attacker who has access to the server. * Receivers don’t need a shared private key but only their own. * Separate server so no other software can influence/impact. Downsides: Downsides: * Nitrokey is out of our control, but we trust Hetzner already (ie. they could easily hook up a malicious USB/BMC device already and gain root privileges). * Server dies, the Nitrokey has to be moved to the new server. Questions: * How to update the key, handle key expiration? * Do we backup the key? Let someone have a separate nitrokey? Setup: * Levente (anthraxx) volunteered to aquire, setup key (+revocation) and get it to Hetzner. -- Jelle van der Waa

Attachments:

signature.asc (application/pgp-signature — 488 bytes)

Show replies by date

Giancarlo Razzolini

11 Feb 11 Feb

8:45 p.m.

Em fevereiro 11, 2019 18:35 Jelle van der Waa escreveu:

...

Options:

* Cheapest Hetzner server 34 euro / month and 40 euro setup fees. * Hetzner auction server ~ 25 / month and no setup fees. * Different dedicated server hoster which allows custom usb devices.

I completely agree this must be on a completely separate server, with as few services on it as possible. So, I'm fine with either options here.

...

Downsides:

* Nitrokey is out of our control, but we trust Hetzner already (ie. they could easily hook up a malicious USB/BMC device already and gain root privileges).

Agreed.

...

* Server dies, the Nitrokey has to be moved to the new server.

This is a risk factor, but then again we have to trust hetzner.

...

Questions:

* How to update the key, handle key expiration?

I'm not sure about the specifics of nitrokey, but if it can be updated remotely, that's fine.

...

* Do we backup the key? Let someone have a separate nitrokey?

I think that we should have a backup key with someone else other than the person that is acquiring the installed key. The whole process should be done independently and these two should meet and make sure that they have identical keys.

...

Setup: * Levente (anthraxx) volunteered to aquire, setup key (+revocation) and get it to Hetzner.

This is something I was going to mention, to avoid issues with interdiction. So, I assume that Levente is going to physically buy and deliver the key to the hetzner datacenter. I would go even further, and ask them if it's possible to follow the physical install procedure. Regards, Giancarlo Razzolini

Florian Pritz

9:48 p.m.

On Mon, Feb 11, 2019 at 09:35:36PM +0100, Jelle van der Waa wrote:

...

For security@archlinux.org the Security Team wants to setup a way for reporters to securely mail encrypted issues to our email address. To limit the bus factor we want to send those emails to multiple receivers and then handle and/or forward the information appropriately. Schleuder providers an solution to this issue by decryping the sent email and re-encrypting it to the Arch Security team members.

Any reason why we don't just follow "The Apache Way"[1] (my term) and list a few of the "core" security people on our website with gpg keys? Then the user has to fetch like 2-4 keys, but I think that's much, much easier and more robust than what is proposed here. This does not require any new keys/servers/software. To make it easier to use, we could put up a file that contains all the relevant keys so that users can import them into GPG in one step. Then we just put up a link that sends to the 2-4 recipients and we are done. With a schleuder based solution, they'd also have to import the schleuder key and then they'd probably click on the email link on some page. I'd say, essentially, both solutions are equal in terms of usability. Doing it "The Apache Way", we also obviously gain full end2end encryption between the reporter and the security team. It is also much clearer for the user who will be able to read their mail, which I believe is quite important when you deal with security issues. Also keeping the recipient list small is good because it limits potentially unwanted exposure. So far I only see benefits with "The Apache Way", where I see a lot of downside with schleuder (difficult setup, additional software, likely rarely used thus might break without us knowing, no actual advantage in terms of usability/security). Am I missing something? [1] https://www.apache.org/security/ Florian

Levente Polyak

18 Feb 18 Feb

2:10 p.m.

On 2/11/19 10:48 PM, Florian Pritz via arch-devops wrote:

...

On Mon, Feb 11, 2019 at 09:35:36PM +0100, Jelle van der Waa wrote:

...
For security@archlinux.org the Security Team wants to setup a way for reporters to securely mail encrypted issues to our email address. To limit the bus factor we want to send those emails to multiple receivers and then handle and/or forward the information appropriately. Schleuder providers an solution to this issue by decryping the sent email and re-encrypting it to the Arch Security team members.

Any reason why we don't just follow "The Apache Way"[1] (my term) and list a few of the "core" security people on our website with gpg keys? Then the user has to fetch like 2-4 keys, but I think that's much, much easier and more robust than what is proposed here. This does not require any new keys/servers/software.

Yes, all this sounds nice and convenient if we are talking about single time reporters that search for a contact to report an issue. However, the primary advantage we wanted to have solved on top are managed/subscribed reporting to CERT. Right now its extremely in-transparent, we have "random" people mapped on their side (and it already contains an inactive dev). What we wish to have is a transparent way to manage first-level receivers on our side (f.e. in ansible) that handle and redistribute the information to the right people on our team. I don't quite like that we need to be aware of who may be registered at CERT and alter it when people resign. Also it could be a good beta test for using a GPG smartcard in the data center that may potentially be handy for future stuff :-) cheers, Levente

Florian Pritz

8:23 p.m.

On Mon, Feb 18, 2019 at 03:10:00PM +0100, Levente Polyak via arch-devops wrote:

...

However, the primary advantage we wanted to have solved on top are managed/subscribed reporting to CERT.

Sorry, I didn't know that. This is indeed a pretty good reason and I'm much more inclined to agree that deploying this might be a good idea. If someone wants to work on this (i.e. create ansible roles), I won't oppose. Some question came to mind though: Do we actually need encryption there? Do they send important/zero-day/private issues or do they just send some form of advisory about already public problems? Or do they require a GPG key before they add you to their contact list? Also, could you give a rough estimate of how many mails per day/month/year we are talking about and how many different senders are involved? Florian

Levente Polyak

19 Feb 19 Feb

9:55 p.m.

On 2/18/19 9:23 PM, Florian Pritz via arch-devops wrote:

...

On Mon, Feb 18, 2019 at 03:10:00PM +0100, Levente Polyak via arch-devops wrote:

...
However, the primary advantage we wanted to have solved on top are managed/subscribed reporting to CERT.

Sorry, I didn't know that. This is indeed a pretty good reason and I'm much more inclined to agree that deploying this might be a good idea. If someone wants to work on this (i.e. create ansible roles), I won't oppose.

I'm sure we will be able to provide them properly, jelle would work on this as well.

...

Some question came to mind though: Do we actually need encryption there? Do they send important/zero-day/private issues or do they just send some form of advisory about already public problems? Or do they require a GPG key before they add you to their contact list?

Yes, it is mostly sensitive pre-notification before information is declared public. They also accept sending it in clear-text, so I guess I will make sure now that we only receive notifications to security@archlinux.org now. We can later update the contact to make them use the new GPG key, I would still prefer if they don't need to send it in clear-text :-)

...

Also, could you give a rough estimate of how many mails per day/month/year we are talking about and how many different senders are involved?

It fluctuates highly, but a rough overall estimate would be something around 6 mails per month with aprox. 4 unique senders (3 of which on regular or semi-regular base). cheers, Levente

Carlos Mogas da Silva

11 Feb 11 Feb

9:54 p.m.

Hi list! On 11/02/2019 20:35, Jelle van der Waa wrote:

...

For security@archlinux.org the Security Team wants to setup a way for reporters to securely mail encrypted issues to our email address. Not actually questioning the motives but, is there really a *need* for this? From now on, I'll assume "yes" here.

...

* Cheapest Hetzner server 34 euro / month and 40 euro setup fees. * Hetzner auction server ~ 25 / month and no setup fees. * Different dedicated server hoster which allows custom usb devices.I would go with an auction server. They're reliable and cheap (had 2 personally already).

...

* Nitrokey is out of our control, but we trust Hetzner already (ie. they could easily hook up a malicious USB/BMC device already and gain root privileges). We can't be *that* paranoid (we actually can, but given the circumstances, I really don't see the need to)

...

* Server dies, the Nitrokey has to be moved to the new server. That's a bummer. Let's not forget downtime to this. How long does it take to Hetzner to move the key? *Who* is allowed to request it?

...

Questions: * Do we backup the key? Let someone have a separate nitrokey? I would vote for "yes" here. Let someone have a backup key that can be used it case the production one get's lost/broken/

Christian Rebischke

12 Feb 12 Feb

7:24 p.m.

On Mon, Feb 11, 2019 at 09:35:36PM +0100, Jelle van der Waa wrote:

...

For security@archlinux.org the Security Team wants to setup a way for reporters to securely mail encrypted issues to our email address. To limit the bus factor we want to send those emails to multiple receivers and then handle and/or forward the information appropriately. Schleuder providers an solution to this issue by decryping the sent email and re-encrypting it to the Arch Security team members.

Since this requires a GPG key to be on the server, we want to implement this securely and hook up a nitrokey pro 2 to a separate Hetzner dedicated server. This server serves the sole purpose of hosting the security mail address. Installing by Hetzner costs 18 euro’s (excl. VAT).

Options:

* Cheapest Hetzner server 34 euro / month and 40 euro setup fees. * Hetzner auction server ~ 25 / month and no setup fees. * Different dedicated server hoster which allows custom usb devices.

Benefits:

* Key can’t be recovered by an attacker who has access to the server. * Receivers don’t need a shared private key but only their own. * Separate server so no other software can influence/impact. Downsides:

Downsides:

* Nitrokey is out of our control, but we trust Hetzner already (ie. they could easily hook up a malicious USB/BMC device already and gain root privileges). * Server dies, the Nitrokey has to be moved to the new server.

Questions:

* How to update the key, handle key expiration? * Do we backup the key? Let someone have a separate nitrokey?

Setup: * Levente (anthraxx) volunteered to aquire, setup key (+revocation) and get it to Hetzner.

-- Jelle van der Waa

Seems like I've missed a discussion on IRC. Please don't read my next lines as stab into your back. First of all I don't understand the problem you want to solve with this solution. In the past we had people who monitor the security@archlinux.org address and I had always the feeling that they did their job good and had no problem with doing it. I always thought that there are not so much mails with security@archlinux.org as recipient. So either my observation was wrong or things has changed.. Let's say the workload has increased. Then I am fully with you and I can understand your problem. On the technical aspects I like your idea, but I can understand Florians point of view as well. Maybe the problem could be already solved via creating a security landing page with a few developer mail addresses and their GPG keys. But here is another argument for the server: We could use it as isolated machine for automatically signing ISO images and Arch Linux images. chris / shibumi

Daniel M. Capella

18 Feb 18 Feb

9:48 a.m.

-- Best, polyzen

Daniel M. Capella

9:48 a.m.

https://securitytxt.org/ -- Best, polyzen

Morten Linderud

9:57 a.m.

On Mon, Feb 18, 2019 at 04:48:57AM -0500, Daniel M. Capella via arch-devops wrote:

...

https://securitytxt.org/

It would be a bit benefitial if you made an argument instead of posting a link. I'll quote somebody elses experience with this, which makes me inclined to believe this is a bad idea in general. "it seems I ended up having endless discussions with people who automated the whole thing: they crawl the web for /.well-known/security.txt URI and if the find it, automatically start-up metasploit or burp-suite and then send you the canned report while asking you to fix these "serious problems". Yet if you quiz any of these "researchers" deeper about individual items in their canned reports you get nothing but blank stares, incompetence and attempts to weasel out: "but burpsuite says that it is an error and you should correct it", ..." https://news.ycombinator.com/item?id=19152145 It's also worth noting that the link is not an argument for, or against, a "security@archlinux.org" address in contrast to a listing of team members. This is just an option to make it known. -- Morten Linderud PGP: 9C02FF419FECBE16

Daniel M. Capella

6:08 p.m.

On February 18, 2019 4:57:16 AM EST, Morten Linderud via arch-devops wrote:

...

On Mon, Feb 18, 2019 at 04:48:57AM -0500, Daniel M. Capella via arch-devops wrote:

...
https://securitytxt.org/

It would be a bit benefitial if you made an argument instead of posting a link.

Learned about it after a check for that file was added to twa[]. Shared as it was relevant.

...

I'll quote somebody elses experience with this, which makes me inclined to believe this is a bad idea in general.

<snip>

...

https://news.ycombinator.com/item?id=19152145

As we're requiring encrypted communications (IIUC), it looks like that's been a fairly effective barrier.

...

It's also worth noting that the link is not an argument for, or against, a "security@archlinux.org" address in contrast to a listing of team members. This is just an option to make it known.

[]: https://github.com/trailofbits/twa -- Best, polyzen

Eli Schwartz

6:21 p.m.

On 2/18/19 1:08 PM, Daniel M. Capella via arch-devops wrote:

...

On February 18, 2019 4:57:16 AM EST, Morten Linderud via arch-devops wrote:

...
On Mon, Feb 18, 2019 at 04:48:57AM -0500, Daniel M. Capella via arch-devops wrote:

...
https://securitytxt.org/

It would be a bit benefitial if you made an argument instead of posting a link.

Learned about it after a check for that file was added to twa[]. Shared as it was relevant.

You shared a contextless link without explaining why it is relevant. Actually, you're still asserting that it is relevant without explaining why it is relevant -- this is particularly intriguing given that it seems other people are counter-asserting that it is not relevant.

...

...
https://news.ycombinator.com/item?id=19152145

As we're requiring encrypted communications (IIUC), it looks like that's been a fairly effective barrier.

Do we require encrypted communications? Or was that simply recommended to other people being brought as comparisons? Either way -- filtering the emails for encrypted communications is still a nonzero task. Why engage in additional efforts to support this security.txt thing, when assertations have been made that it is not beneficial at all, and furthermore, the *location* where the list of security contacts is stored is entirely offtopic in this discussion about unifying the actual contacts to list, as a method of preventing leakage and other confusion when members are added and removed from that list, and/or the potential for people with outdated information to encrypt data to a recipient that is no longer supposed to have access to such information. -- Eli Schwartz Bug Wrangler and Trusted User

1898

Age (days ago)

1906

Last active (days ago)

List overview

Download

12 comments

9 participants

participants (9)

Carlos Mogas da Silva
Christian Rebischke
Daniel M. Capella
Eli Schwartz
Florian Pritz
Giancarlo Razzolini
Jelle van der Waa
Levente Polyak
Morten Linderud

[arch-devops] security@archlinux.org address

tags

participants (9)