- Arch-devops - lists.archlinux.org

[arch-devops] [RFC] Better security through Content Security Policy and other headers.
by Jelle van der Waa 04 Aug '18

04 Aug '18

Hi All, Below is a proposal to increase our websecurity for *.archlinux.org # Goal Better security through Content Security Policy and other headers. # How Either sending CSP headers via nginx or modifying the web application to send the correct headers. Configuring via nginx is probably the easiest way to distribute these changes. # Which sites bugs.archlinux.org bbs.archlinux.org wiki.archlinux.org git.archlinux.org pkgbuild.com pkgbuild.com/~* mailman.archlinux.org kanboard.archlinux.org planet.archlinux.org archlinux.org (django) aur.archlinux.org Excluded is security.archlinux.org, which already includes all of the below headers via flask-talisman. # Which headers ## X-XSS-Protection The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. This is mostly superseded by CSP, but still is not harmfull to add. add_header X-Xss-Protection "1; mode=block" always; ## X-Content-Type-Options The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. Check bugtracker/archweb if this breaks attachments or other files which are download. add_header X-Content-Type-Options "nosniff" always; ## X-Frame-Options The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. I don't believe we want to allow embedding our websites. add_header X-Frame-Options "SAMEORIGIN" always; ## Content-Security-Policy The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS). This might differ a bit per site, Archweb for example requires unsafe-inline / unsafe-eval for JavaScript and CSS. But all our loaded content should be from the same origin and restricted. An example policy would be: add_header Content-Security-Policy "default-src 'self'; style-src 'self'; font-src 'self'; form-action 'self';" # Challenges * inline JavaScript => archweb/aurweb => use a nonce or rewrite. * inline CSS => archweb/aurweb => use a nonce or rewrite. * unsafe-eval => this should never be allowed and should be fixed # Verifying The following website nicely shows the enabled security headers. https://securityheaders.com/ More information about these headers can be found here. https://scotthelme.co.uk/hardening-your-http-response-headers/ -- Jelle van der Waa

2 1

[arch-devops] Secondary backup ideas (Task #50)
by Phillip Smith 27 Jul '18

27 Jul '18

(Sorry, I can't reply to the original thread as I wasn't a member of the list at the time) Can I throw restic[0] in to the mix? It's very similar to borg, but super fast[1]. I moved away from borg a while ago for various reasons. It's written in golang, so it's a simple ELF executable to deploy. Supports lots of destinations[2] and multiple keys [3]. Specifically, I'm thinking the multiple key feature would allow us to have the client push backups to the backup server over a read-only connection (SSH, S3, rsync, whatever), then be able to run restic server-side to handle the cleanups. Anyway, 'food for thought' that we can discuss. Cheers, ~p [0] https://restic.net/ [1] My home desktop backup: ~121gb of source data on spinning-rust (not SSD); incremental backup takes ~8 seconds: scanned 11482 directories, 72707 files in 0:01 [0:07] 100.00% 13.298 GiB/s 121.249 GiB / 121.249 GiB 84189 / 84189 items 0 errors ETA 0:02 duration: 0:07, 15798.45MiB/s snapshot 8c4aea6d saved [2] https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html [3] https://restic.readthedocs.io/en/stable/070_encryption.html

3 5

[arch-devops] archweb questions
by Ross Boulet 23 Apr '18

23 Apr '18

Just a curiosity question. I posted a question [1] to the Arch Linux Forums regarding a function on the Arch website. Someone suggested I file a bug report, so the developers would be aware. But I looked at the "Projects in Git" [2] from the Arch Linux home page and did not see any recent updates to "archweb". I posted a question [3] in the arch-mirrors mailing list and was referred here. This leads me to a couple of questions: First, have I done all the reporting needed to get this issue to the proper place? Second, is the "archweb" in the git at [2] the same thing as the website, and if so, why didn't it show any updates? Thanks [1] https://bbs.archlinux.org/viewtopic.php?pid=1781381 [2] https://git.archlinux.org/ [3] https://lists.archlinux.org/pipermail/arch-mirrors/2018-April/000736.html -- Ross Boulet rossb(a)rossb.com -

3 3

Re: [arch-devops] [arch-dev-public] Archweb (archlinux.org) upgrade
by Giancarlo Razzolini 21 Apr '18

21 Apr '18

Em abril 19, 2018 17:04 Jelle van der Waa escreveu: > Hi all, > > Tommorow evening we will be updating https://archlinux.org (archweb), so > expect some downtime due to upgrading. Since it's a major version bump > 1.8 => 1.11 some issues might occur, but in general it should be a > smooth upgrade (tm). > > P.S. Next up is porting archweb to Python 3, any help is appreciated! > Hi all, I expect we should have a downtime of about 1-2 hours. If you notice anything different post upgrade, please let us know. Both me and Jelle are going to probably be around on IRC too during the upgrade. Regards, Giancarlo Razzolini

2 2

[arch-devops] Fwd: Archweb (archlinux.org) upgrade
by Jelle van der Waa 19 Apr '18

19 Apr '18

----- Forwarded message from Jelle van der Waa <jelle(a)vdwaa.nl> ----- > Date: Thu, 19 Apr 2018 22:04:21 +0200 > From: Jelle van der Waa <jelle(a)vdwaa.nl> > To: arch-devops(a)archlinux.org, arch-dev-public(a)archlinux.org > Subject: Archweb (archlinux.org) upgrade > > Hi all, > > Tommorow evening we will be updating https://archlinux.org (archweb), so > expect some downtime due to upgrading. Since it's a major version bump > 1.8 => 1.11 some issues might occur, but in general it should be a > smooth upgrade (tm). > > P.S. Next up is porting archweb to Python 3, any help is appreciated! > > -- > Jelle van der Waa ----- End forwarded message ----- -- Jelle van der Waa

1 0

[arch-devops] Question Regarding Appstream Data
by Christopher Davis 16 Apr '18

16 Apr '18

Hello arch-devops, I am curious about the files used by archlinux-appstream-data. My goal is to create a parabola-appstream-data for Parabola GNU/Linux-libre. According to some people in #parabola on Freenode, the files the PKGBUILD for archlinux-appstream-data are generated on your servers with appstream-generator. Could you provide some information on your setup for this? Regards, Chris

3 2

[arch-devops] Archweb upgrade to django to 1.11
by Jelle van der Waa 15 Apr '18

15 Apr '18

I've made a PR to update archweb to 1.11 the latest LTS version of django. [1] It's running on the staging env currently and no particular bugs have been found yet. Note that the staging env does not sync new packages, which I would love add soon (tm). [2] When this is merged, I'd like to deploy it as soon as possible on our production env. After this merge I want to focus on Python 3 / Django 2.0 although this is not a LTS release. (Python 3 alone should be enough work tbh). When would be a good time for an upgrade? Angvp / grazzolini please review the PR so it can be merged. [1] https://github.com/archlinux/archweb/pull/88 [2] https://archweb-dev.archlinux.org/ -- Jelle van der Waa

2 2

[arch-devops] Curious about Arch repository policy
by Sudarshan Kakoty 27 Mar '18

27 Mar '18

Hello; I was reading "Arch Wiki" and felt curious about that difference between extra and community repo. Some packages, such as "meson" is in the "extra" repo, whereas "ninja" is in "community" repo. The interesting fact is that - "ninja" is an implicit dependency to "meson". So why that is (ninja) in the community repo? Also, some critical GNOME specific packages are part of the community repo. Even, some compilers, like Haskell is also part of the community repo. What is the exact difference between extra and community repository? I wonder, Is it really important to have that split?

2 1

[arch-devops] Host-based Firewalls (Task #61)
by Phillip Smith 08 Mar '18

08 Mar '18

Hi all, I've spent a couple of hours looking in to task #61 ("Set up firewall"). It should be pretty straight-forward. I've reviewed each of the Hetzner hosts for the ports they are listening on vs what should be publicly accessible. I have a diff against the current ansible roles if someone would like to review and give me their thoughts? Cheers, ~p

2 5

[arch-devops] LDAP role
by Giancarlo Razzolini 06 Mar '18

06 Mar '18

Hi Guys, Now that the wiki was migrated, I'm starting to work on the LDAP role. But, since this will certainly be a complex role and it will involve a lot of other roles/applications, I want to discuss with you some of the approaches we can take. First of all, we need to choose on the Directory Service application that we are going to use: 1) OpenLDAP [0]: It's the established open source directory server and the basis for many others. We have it on [core]. It does support having more than one server, either in master-slave or multi-master (I'll talk more about topology below). Pros: Being the "de facto" implementation and well know. It's relatively easy to setup and has multiple options for topology. Cons: It doesn't have any GUI tool for management and needs external projects (like phpldapadmin) to do so. Adding users sometimes requires messing with LDIF's and others. 2) 389-ds (formerly fedora ds) [1]: It's the second contender here. I have personally used it extensively in the past, so I might be biased towards it. It does not have an official package, but there is one on the AUR [2]. Pros: It is very easy to setup and comes up the console tool for management which is a java GUI. Also has a great multi-master replication support. Cons: We don't package it currently and it's somewhat more intensive on resource usage than OpenLDAP. 3) FreeIPA [3]: It is basically a bundle of a lot of software that is complimentary to a DS but not always required, like DNS, NTP server, Kerberos and PKI. It's DS part is provided by 389-ds. Pros: Easier to setup than OpenLDAP, has a nice web management tool and comes with a lot of pre-configured stuff. Cons: It is complex and has a lot of stuff that's not required for our use case. Also does not have an official package, and doesn't have a server package on the AUR either. 4) Samba 4 [4]: Since Samba 4, you can create one DS quite easily, there's even a wizard for it. It uses OpenLDAP, bind and some other bundled stuff behind the scenes, just like FreeIPA does. Pros: It is quite easy to setup and we have it packaged. Cons: It is more meant for AD integration and I think we can assume there won't be any possibility of that happening in the near future. There are some other options, but they are either outdated or do not provide everything we need. Having discussed DS software options, I want to discuss regarding the topology. The idea is to eventually bring all the applications and systems authenticating to this DS. In order for us to do that, more than one will be required to handle the load. We have the master-slave relationship or the multi-master one. There are arguments pro and con to both, but I like the description that the OpenLDAP documentation gives [5]. I would say for us to set a master and each machine having its own slave server running. TLS should be used everywhere, but I don't think we need to set TLS client authentication, at least, not for now (see below). We have to define if we are going to use the plain internet for this or some private network. I'm bringing this up right now, because we need to decide if we are going to allow anonymous connections to the DS (I'm against it) to query for users or not. Basically if we are going to allow anyone to query it or not. If not, then we need to use SASL or other mechanism for authenticating the clients, which compounds on the complexity. There's also the possibility of limiting the fields that anonymous clients can query, as well as the number of queries/responses. This would be similar to the AUR TOS case, but for everything, so it should be discussed upfront. I'm eager to hear your replies and whatever we decide here we should bring to adp for further enhancements. I don't want to turn this into a bikeshed discussion, though. So, keep your ideas within the limits of what was presented. Regards, Giancarlo Razzolini [0] https://www.openldap.org/ [1] http://directory.fedoraproject.org/ [2] https://aur.archlinux.org/packages/389-ds-base/ [3] https://www.freeipa.org/page/Main_Page [4] https://www.samba.org/ [5] http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master%2…

4 6