NethServer has a simple rule about changing defaults settings. It can happen when a new minor ISO is released and affects only new installations.
So, starting from NS 7.5, new installations will enforce a GDPR-compliant TLS policy. Existing installations must be upgraded manually.
I hope we all agree on this rule!
I agree with @davidep on this one - the next release should be GDPR-compliant if possible.
If it is not possible, for the areas where it is known to not be compliant, the reasons for it should be well documented with proposals and/or plans on how to make it GDPR compliant (and with estimated reasonable timescales if possible) for transparency purposes. I know this may be difficult having done dev work myself, but it is something good to strive for.
For the earlier releases, I would recommend having a document somehow on the steps required to help make it GDPR complaint based on the list of software that NethServer lists in the GUI and with a caveat statement advising that any other software that is installed outside of that list is up to the sysadmin to ensure that it is configured correctly for GDPR compliance.
We have a name for the new version 
after Gnocchi
NethServer 7.5 GDPR-compliant
Seems more professional 
I am sorry, but a GDPR compliant server does not exist.
It sure helps on the transport side of things if Nethserver is as secure as possible, but this will mainly aid to get 27001 compliant, when the GDPR applies to you.
The GDPR is just a set of rules demanding privacy by default. It identifies Personal Information in a way that everything directly linked to a person, is it. It then demands that one has rules and regulations in place on who can handle that PI and when, and for what exact purpose. Any other use is prohibited and leads to a data-breach that you are required to report.
Other then that, it demands that people can be forgotten. This requires pseudonomisation of log-files and something like a checkmark to add to an account, that will irreversibly erase the personal data and have the pseudonim return john doe.
It also demands that all data present on the system be exportable in easy to carry format, as well as it being requestable by the person.
If you guys are gonna make it so that this works throughout the distribution, you can claim it is compliant, and youâd be insane 
In reality, GDPR requires companies to limit acces to PI to a âneed-to-handleâ basis, and be able to erase data, including data in log-files, and upon restore of old backups. It also requires a complete audit-trail to who had what access to what PI at what time and why was that warranted. Most of this is procedures and access-rights related stuff, and hardly applies to server installations beyond the requirement to be able to transport using secure means. That alone does not make it compliant tho.
Edit: Strictly, when an employee leaves and uses these rights, we need to erase all PI on them as well, and that will be a major PITA on every server distribution there is, forcing companies to either not log stuff that could possibly contain PI, or say âf*** it, lets see what happens in court when it gets to thatâ.
Also, when you are required by law to have records, that in and of itself is enough reason to not comply with a request to be forgotten. Think medical data, or employee data.
Ok letâs change the subject of this thread to SSL hardening only 
I understand that what we could improve is the delete user account scenario. We recorded a project card to automatically remove user data
NethServer 7 · GitHub (GitHub auth required)
âŠbut it can work only with local accounts provider. In other words, we cannot remove user data automatically if NethServer is configured with a remote LDAP or AD account provider.
About log files: they are not included in backup. The default logrotate policy is weekly rotation, retain 4 weeks (52 on Enterprise). Usually the log details helps to understand what a user is doing with each service. Pseudonymization is not applied to the default local log files (under /var/log).
Hi, a am a newbie of Nethserver (ok, not that newbie), where is the prop and the user interface section to tweak/increase/change log retention policy?
@alefattorini so no one will get a GDPR compliant release before Nethserver 7.5?
Why European sysadmins should have interest into the project if it wonât be working as requested at 23/5/2018? The hope of a GDPR compliant release should let this project more interesting than others?
A little search gives much information
https://www.google.com/search?q=nethserver+log+retention
What does exactly mean? How does this requirement translates to new feature requests and how could they be implemented?
I talked saturday with someone working in a company, developing a medical software, they are really concerned by the GDPR due to the personal informations they collect, use, store and so long.
They receive a memo a bout my contact, but for now they did nothing, although the fines could be really expensive
Nethserver is not a website and I have some difficulties to understand how it could be GDPR compliant, it is what the sysadmin does with it which must be GDPR compliant.
EDIT: reading the post of @planet_jeroen, it is likely infeasible, email log must be retained during one year in france (for example)âŠyes it needs to see how the court and trial will do with that.
Even if a âGDPR Compliantâ release does occur in the next 6-8 weeks it would be completely and utterly impractical for everyone to reinstall both Dev and Production before the due GDPR comes into effect, especially when it would only cover a small portion of the compliancy as @planet_jeroen quite rightly pointed out. Its down to the configuration settings which weâre busy fleshing out.
I would say that once the basic settings for things like SSL, Log Rotation, Backups, Email, etc are agreed, one could then apply those settings to current installations.
One needs to balance the settings out with other current legislation as @stephdl has pointed out and if someone does get dragged into court because of a conflict between GDPR and current legislation, step back and let the legal professionals duke it out, just make sure that you are able to prove that you have done due diligence and done your best to comply with GDPR in an open and transparent way.
That is the main message of the GDPR. And pseudonimisation is a huge pro, but not always practical. Looking (well, having someone look) into Elastic Stack to scrub the logs atm. Or at least limit how they are displayed and who can view them. Looking promissing.
Also, PI is everything that can lead to a natural person, including IPâs, so logs just became gold.
The main message of the GDPR is:
Non of this requires a compliant server . ⊠you can run a Windows 3.11 for all I care, as long as you isolate it from the network and make sure that only those systems that should be able to connect, are able to connect, and monitor the F out of it ⊠that should pass.
We are (albeit late) bussy with this topic atm, if anything comes up, I will post here. We are a âbespoke softwareâ company in the medical market ⊠our clients need to be compliant, we are just catering to their demands. But even in our case, there is a lot to be done, and requests by customers will slowly but surely define how the medical establishment feels they need to handle this.
As a supplier, you WILL be a processor of PI, if your personel has access to it. This makes it of the utmost importance to update your contracts, and have this legaly verified before you sign off on those.
Even if the software is able to support all requirements put on businesses with the advent of the GDPR, it still is NOT compliant as long as the procedures are not in place, and all PI is mapped and documented.
This will never be some automatic proces, you will have to document that as the data officer of your company. From there, you will be telling people where the proces needs hardening or where the servers need hardening, or whatever else you deem needed to get compliant.
Legacy systems will not be able to comply either ⊠that can be entirely fixed on the procedural end or by virtualizing apps, and yes, that means homework that you will not be able to complete in time, if you still have to start.
No amount of pre-thinking and making the distribution âcompliantâ will do you any good on the GDPR side of things, it will just make for easy ticks on the 27001 side of things.
@stephdl, Iâve seen your PR here and I think Iâve some points that are worth discussing here.
So far, the SSL settings have been retained to distro defaults, as our general rule is âfollow upstreamâ. httpd-admin is one exception: as its configuration is not provided by upstream, we hardened the SSL settings a bit. Both httpd-admin and httpd have a special SSLCipherSuite that tweaks the SSL settings. All of this constitutes the âlegacyâ policy.
Having said that, what Iâve got in mind to define and apply future policies is:
tls/policy prop valueNow we can decide how to deal with SSLCipherSuite for httpd and httpd-admin values: do they always win over tls/policy implementation? Iâd say: no! They are honored by legacy policy only, to retain backward compatibility. Who decides to upgrade gets a configuration that ignores those props and applies the pre-defined hardened settings.
With this approach, I think we do not need to implement any policy âexemptionâ mechanism. As usual, if someone needs an exemption/customization the template-custom approach should be possible, so Iâd care to design our templates in a way that can be easily overridden by template-custom.
In this case, if we take care to make a template easy for customisation, why not implement a hidden prop enabled/disabled to force the legacy cipher. It is better than a custom template.
Concerning the Cipher to decide, honestly it is a big field, I found this https://bettercrypto.org/ and their guide https://bettercrypto.org/static/applied-crypto-hardening.pdf.
What I find nice is that it is a consistent guide for cipher among all services, but you might have a better one, please give your hints.
agreed
I donât think it is a real scenario. httpd-admin is likely to not need an exemption, as a responsible sysadmin must install modern browser in his laptop.
Every prop we implement must be developed and documented, it needs a verified test case and to be known by support people. A custom template (even documented) is much more lightweight and sustainable.
I donât have much experience on this field, Iâm sorry I canât help. Letâs start with a simple hardened receipe for public services: weâll test it and we can refine it in future releases.
The list of public services from GitHub: those that are by default accessible from red zone
Iâm still missing ejabberd and openvpn. @stephdl did you find some receipe for them?
Cockpit claims to be secure by default 
http://cockpit-project.org/guide/149/https.html#https-compat
for openvpn
yes we have a clue, my concern is to get the same cypher and auth directives in the client configuration, this could drive to issue. But it should work.
https://bettercrypto.org/static/configuration/VPNs/OpenVPN/server.conf
https://bettercrypto.org/static/configuration/VPNs/OpenVPN/client.conf
for ejabber
not really looked
In fact we have a good starting point for studying all services : https://bettercrypto.org/static/applied-crypto-hardening.pdf