Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Monday, July 22, 2013, Reindl Harald h.rei...@thelounge.net wrote: Am 22.07.2013 18:37, schrieb Miloslav Trmač: On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Jul 22, 2013 at 04:53:36PM +0200, Miloslav Trmač wrote: On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr I think it's generally known by now that I don't like namespaces as a security mechanism. At best, this is duplicating SELinux policy with less transparency and worse tools. Namespaces really aren't duplicating SELinux policy, they are working in a complementary fashion. There is clear value in having multiple layers of security defence because things do fail for any number of reasons. The returns to additional layers enforcing the same policy are rapidly diminishing, though. We already have DAC permissions, and MAC policy, and a third layer is being proposed. Why not have four or ten? We have to stop somewhere. depends on the cost and impact the cost for two lines in the systemd-unit is low there is no measurable performance impact there is no such impact as mount /usr read-only so cronjobs and whatever are working as before while network-service is more protected it steps in where SElinux is disabled or in permissive mode (The network services shouldn't be running as root in the first place.) No argument there, but even if something is running as non-root there is the potential for privilege escalation through security flaws in some thing that they use. In such a scenario having a separate filesystem namespace which has made certain areas read-only may well stop the exploit. If I am able to escalate to root privileges, I can just switch back to the system namespace using setns(2), so the protection doesn't actually exist. in theory yes practically a exploit is not that easy like fire a bundle of commands as root like a script So we're talking about limited circumstances where the attacker can modify files and not execute code, or where the attacker is root but not CAP_SYS_ADMIN (or whatever it is) a httpd running with SElinux disabled or in permissive mode with Here is your problem ... How about running it in enforcing mode? I mean you care ab out security and disable security features at the same time. If there are selinux bugs file and/or fix them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 25.07.2013 17:57, schrieb drago01: in theory yes practically a exploit is not that easy like fire a bundle of commands as root like a script So we're talking about limited circumstances where the attacker can modify files and not execute code, or where the attacker is root but not CAP_SYS_ADMIN (or whatever it is) a httpd running with SElinux disabled or in permissive mode with Here is your problem ... How about running it in enforcing mode? I mean you care ab out security and disable security features at the same time. If there are selinux bugs file and/or fix them if you are able to marry pure-ftpd, samba and 250 cms-installations predictable on a machine running also *self developed* managment-software for a complete infrastructure on 20 Fedora servers with SElinux go ahead :-) been there done that and it makes thiings so secure that they are completly unuseable because you are searching all day long for problems acess denied here and there however, if nobody is interested in my proposal i am fine since i do not use the fedora packages for critial services and the own infrastructure is using systemd-units how we want, need and can predictable support them signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Mon, 22.07.13 00:02, Reindl Harald (h.rei...@thelounge.net) wrote: Hi has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr So, I could agree to this part. additionally having the RPM database to accessable for network-services is fine, set for all listed below and reduces the attack surface InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/yum This part gives me a headache though. ReadOnlyDirectories=/etc /usr simply encodes the semantics that we generally assume that /etc and /usr have, in a single configuration option: /etc and /usr are generally read-only during runtime, and only writable when configured or new packages are installed. A setting like this should pretty universally work for all services with very few exceptions. This is why I like this. However, the rpm/yum lines come awfully close to a MAC solution which labels all objects and assign access modes to them. It is also much less universal as these files/dirs may rightfully be accessed by a number of system services. systemd should not be misunderstood as a reimplementation of SELinux or AppArmor, hence finegrained labelling of specific files and dirs sounds like nothing we should do. OTOH making /etc and /usr read-only just means enforcing generally assumed semantics of these top-level directories, and so I'd be happy to. So, yeah, if somebody wants to work on getting ReadOnlyDirectories=/etc /usr into the packaging guidelines as proposed default for all system services, I'd certainly support that, but since I have enough of discussing and dealing with Fedora committees and discussion forums this is something somebody else has to champion or won't happen. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 25.07.2013 19:48, schrieb Lennart Poettering: On Mon, 22.07.13 00:02, Reindl Harald (h.rei...@thelounge.net) wrote: has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr So, I could agree to this part. which is my proposal additionally having the RPM database to accessable for network-services is fine, set for all listed below and reduces the attack surface InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/yum This part gives me a headache though which was not part of my proposal but could be considered additionally for services which have never to deal with the rpm-database like httpd ReadOnlyDirectories=/etc /usr simply encodes the semantics that we generally assume that /etc and /usr have, in a single configuration option: /etc and /usr are generally read-only during runtime, and only writable when configured or new packages are installed. A setting like this should pretty universally work for all services with very few exceptions. This is why I like this. However, the rpm/yum lines come awfully close to a MAC solution which labels all objects and assign access modes to them. It is also much less universal as these files/dirs may rightfully be accessed by a number of system services. see above systemd should not be misunderstood as a reimplementation of SELinux or AppArmor, hence finegrained labelling of specific files and dirs sounds like nothing we should do. OTOH making /etc and /usr read-only just means enforcing generally assumed semantics of these top-level directories, and so I'd be happy to i do not mistunderstand it it comes *additionally* to it, could be a sane default and setps in when a) SElinux which is fine granted may fail for whatever reason or is not possible to enforce depending on the environment having a cheap and easy to maintain *additional* barrier is mostly a good idea and the biggest benefit of this systemd-features are that they only protect network-aware services this draws a nice line between having /usr on a own read-only mounted partition with all the side-effects in administration and space-allocation in cloud environments while reach a compareable goal So, yeah, if somebody wants to work on getting ReadOnlyDirectories=/etc /usr into the packaging guidelines as proposed default for all system services, I'd certainly support that, but since I have enough of discussing and dealing with Fedora committees and discussion forums this is something somebody else has to champion or won't happen i understand this well, the for me interesting services have their units in /etc/systemd/system/ or a from the internal repos where i build *most* for our infrastructure from source (anything related to web-and mai-services) if someone takes this global or maintainers of specific services agree and include it for their packages like httpd which is the most attacked and sensible one by the fact that PHP and whatever languages expose exec(), system()... is a different thing and has no impact in my decision use it for all servers i am responsible for since some days and i am *really thankful* to have this option signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 25.07.2013 17:57, schrieb drago01: in theory yes practically a exploit is not that easy like fire a bundle of commands as root like a script So we're talking about limited circumstances where the attacker can modify files and not execute code, or where the attacker is root but not CAP_SYS_ADMIN (or whatever it is) a httpd running with SElinux disabled or in permissive mode with Here is your problem ... How about running it in enforcing mode? I mean you care ab out security and disable security features at the same time. If there are selinux bugs file and/or fix them if you are able to marry pure-ftpd, samba and 250 cms-installations predictable on a machine running also *self developed* managment-software for a complete infrastructure on 20 Fedora servers with SElinux go ahead :-) You missed the and/or fix and file bugs part. It does not work so lets disable it and add hacks to get the same functionality back is bad practice. If it does not work we should fix it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 25.07.2013 20:31, schrieb drago01: On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 25.07.2013 17:57, schrieb drago01: in theory yes practically a exploit is not that easy like fire a bundle of commands as root like a script So we're talking about limited circumstances where the attacker can modify files and not execute code, or where the attacker is root but not CAP_SYS_ADMIN (or whatever it is) a httpd running with SElinux disabled or in permissive mode with Here is your problem ... How about running it in enforcing mode? I mean you care ab out security and disable security features at the same time. If there are selinux bugs file and/or fix them if you are able to marry pure-ftpd, samba and 250 cms-installations predictable on a machine running also *self developed* managment-software for a complete infrastructure on 20 Fedora servers with SElinux go ahead :-) You missed the and/or fix and file bugs part you missed the *self developed* managment-software It does not work so lets disable it and add hacks to get the same functionality back is bad practice. no, using as much as possible security options without damage the operational work is the one and only practice if it comes to *business* and a lot of people living from 365/24/7 up services with no permissions denied where it is not intented If it does not work we should fix it *you* can *not* fix anything in packages in my case these are over more than 10 years grown environments responsible for over 600 domains which was migrated from MacOSX to Fedora years ago, there are a *lot* of packages involved which are not existing for Fedora in the public signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Thu, Jul 25, 2013 at 8:39 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 25.07.2013 20:31, schrieb drago01: On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 25.07.2013 17:57, schrieb drago01: in theory yes practically a exploit is not that easy like fire a bundle of commands as root like a script So we're talking about limited circumstances where the attacker can modify files and not execute code, or where the attacker is root but not CAP_SYS_ADMIN (or whatever it is) a httpd running with SElinux disabled or in permissive mode with Here is your problem ... How about running it in enforcing mode? I mean you care ab out security and disable security features at the same time. If there are selinux bugs file and/or fix them if you are able to marry pure-ftpd, samba and 250 cms-installations predictable on a machine running also *self developed* managment-software for a complete infrastructure on 20 Fedora servers with SElinux go ahead :-) You missed the and/or fix and file bugs part you missed the *self developed* managment-software No I did not. The selinux policy is supposed to work fine for them as well. You can even amend the policy for your specific needs. It does not work so lets disable it and add hacks to get the same functionality back is bad practice. no, using as much as possible security options without damage the operational work is the one and only practice if it comes to *business* and a lot of people living from 365/24/7 up services with no permissions denied where it is not intented If it does not work we should fix it *you* can *not* fix anything in packages Sure I can done that countless times in the past or IOW no idea what that is supposed to mean. in my case these are over more than 10 years grown environments Irrelevant. responsible for over 600 domains which was migrated from MacOSX to Fedora years ago, Irrelevant. there are a *lot* of packages involved which are not existing for Fedora in the public There might still be bugs in them (and/or in the selinux-policy package). Being more specific would be way more productive. Like my app tries to do X but fails with the following message. You don't have to run enforcing straight out. You can start with permissive, fix the bugs / your configuration and once you have done that switch to enforcing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Hi On Thu, Jul 25, 2013 at 1:48 PM, Lennart Poettering wrote: So, yeah, if somebody wants to work on getting ReadOnlyDirectories=/etc /usr into the packaging guidelines as proposed default for all system services, I'd certainly support that, but since I have enough of discussing and dealing with Fedora committees and discussion forums this is something somebody else has to champion or won't happen. I don't really understand the need for adding more boilerplate to every since instead of treating it as systemd default and providing a way to opt out if necessary Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Thu, Jul 25, 2013 at 9:01 PM, Reindl Harald h.rei...@thelounge.net wrote: There might still be bugs in them (and/or in the selinux-policy package). Being more specific would be way more productive. Like my app tries to do X but fails with the following message my app does not exist outside the own infrastrcuture How does that even matter? That does not mean that your app is unfixable. Unless it is a closed source thing and your developer left. I have a custom developed app that tries to do X but then I get an AVC like . is a completely valid bug report. You will either get an answer like do it that way instead and it will work or oh this is a bug fixed in selinux-policy version foo.x.y -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.rei...@thelounge.net wrote: if you are able to marry pure-ftpd, samba and 250 cms-installations predictable on a machine running also *self developed* managment-software for a complete infrastructure on 20 Fedora servers with SElinux go ahead :-) been there done that and it makes thiings so secure that they are completly unuseable because you are searching all day long for problems acess denied here and there That can happen with SELinux when the application does something unanticipated by the policy writers. It can also happen just the same with ReadOnly Directories, for just the same reason, can't it? I suppose there may a difference in how often that happens - /usr is read only is a fairly well-targeted heuristics, OTOH /usr is read only also leaves a large part of the system completely unprotected. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 25.07.2013 21:06, schrieb drago01: On Thu, Jul 25, 2013 at 9:01 PM, Reindl Harald h.rei...@thelounge.net wrote: There might still be bugs in them (and/or in the selinux-policy package). Being more specific would be way more productive. Like my app tries to do X but fails with the following message my app does not exist outside the own infrastrcuture How does that even matter? That does not mean that your app is unfixable. Unless it is a closed source thing and your developer left. the developer am i I have a custom developed app that tries to do X but then I get an AVC like . is a completely valid bug report. You will either get an answer like do it that way instead and it will work or oh this is a bug fixed in selinux-policy version foo.x.y you refuse to understand that do it that way instead is no otpion for some hundret thousand lines of code working *perfectly* since years and have to work togehter on a whole cluster however, im am not interested to discuss a lifetime-work doing exactly as it should which can be *more* secure as it already is with two lines in a systemd-unit which is done, up and working for hours someone may consider to do the same or not it does not have impact on my workload signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 25.07.2013 21:26, schrieb Miloslav Trmač: On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.rei...@thelounge.net wrote: if you are able to marry pure-ftpd, samba and 250 cms-installations predictable on a machine running also *self developed* managment-software for a complete infrastructure on 20 Fedora servers with SElinux go ahead :-) been there done that and it makes thiings so secure that they are completly unuseable because you are searching all day long for problems acess denied here and there That can happen with SELinux when the application does something unanticipated by the policy writers. It can also happen just the same with ReadOnly Directories, for just the same reason, can't it? no it can't there is a difference between write to /usr and write to a bind-mount under /usr/local which is not part of the OS as well as other trees on disks far away from the FHS layout I suppose there may a difference in how often that happens - /usr is read only is a fairly well-targeted heuristics, OTOH /usr is read only also leaves a large part of the system completely unprotected correct but in environments like mine it includes *anything* installed from packages and leaves out *anything* of own driven software which needs write-access and can only with a lot of (too) much effort be married with selinux i tried SElinux several times on clones and finally it was way too much unpredictable work to arrange it with the running infrastructure while make /ur and /etc read-only was done and tested for any service within a few hours i am perfectionist but at the same time i have to draw a line between perfect and doable without killing the companies workspace the proposal draws the line in a perfect way, has no measureable performance impact and doe swork nicely on systems with enforced SElinux - that is why one of my first thougts was hey why is this not the default? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 25.07.2013 20:51, schrieb drago01: *you* can *not* fix anything in packages Sure I can done that countless times in the past or IOW no idea what that is supposed to mean. it means webinterfaces nobody outside our company will ever be possible to touch or see controlling httpd, dbmail, postfix, trafficserver, dhcpd, dovecot, named, unbound, prosody, asterisk and bring them together in *one* unique web-interface and spread over 20 machines if you visiit vienna ping me and i will show you things most can not imagine running on Fedora since F9 and yum-upgraeded all the years while mostly devleopd outside Linux until 2008 in my case these are over more than 10 years grown environments Irrelevant for you... responsible for over 600 domains which was migrated from MacOSX to Fedora years ago, Irrelevant for you there are a *lot* of packages involved which are not existing for Fedora in the public There might still be bugs in them (and/or in the selinux-policy package). Being more specific would be way more productive. Like my app tries to do X but fails with the following message my app does not exist outside the own infrastrcuture signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 22.07.2013 18:37, schrieb Miloslav Trmač: On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Jul 22, 2013 at 04:53:36PM +0200, Miloslav Trmač wrote: On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr I think it's generally known by now that I don't like namespaces as a security mechanism. At best, this is duplicating SELinux policy with less transparency and worse tools. Namespaces really aren't duplicating SELinux policy, they are working in a complementary fashion. There is clear value in having multiple layers of security defence because things do fail for any number of reasons. The returns to additional layers enforcing the same policy are rapidly diminishing, though. We already have DAC permissions, and MAC policy, and a third layer is being proposed. Why not have four or ten? We have to stop somewhere. depends on the cost and impact the cost for two lines in the systemd-unit is low there is no measurable performance impact there is no such impact as mount /usr read-only so cronjobs and whatever are working as before while network-service is more protected it steps in where SElinux is disabled or in permissive mode (The network services shouldn't be running as root in the first place.) No argument there, but even if something is running as non-root there is the potential for privilege escalation through security flaws in some thing that they use. In such a scenario having a separate filesystem namespace which has made certain areas read-only may well stop the exploit. If I am able to escalate to root privileges, I can just switch back to the system namespace using setns(2), so the protection doesn't actually exist. in theory yes practically a exploit is not that easy like fire a bundle of commands as root like a script So we're talking about limited circumstances where the attacker can modify files and not execute code, or where the attacker is root but not CAP_SYS_ADMIN (or whatever it is) a httpd running with SElinux disabled or in permissive mode with the 4 lines below even after escalate to root privileges will hardly have a chance to overwrite /usr/sbin/sshd as example CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID NoNewPrivileges=yes ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 22.07.2013 18:10, schrieb Nicolas Mailhot: Le Lun 22 juillet 2013 00:02, Reindl Harald a écrit : has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr It would be very nice if write-protection of FHS-defined RO directories was applied by default, except for the software updater or during explicit maintenance operations the idea behind my proposl is to reach nearly the same as a system-wide write-protection or mount read-only without impact maintenance - i see it as compromise i do not want to have a webserver exploited and damage my system while i do not want /usr globally read-only which would kill cronjobs and own software running on top of Fedora in /usr/local signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Reindl Harald (h.rei...@thelounge.net) said: a httpd running with SElinux disabled or in permissive mode with the 4 lines below even after escalate to root privileges will hardly have a chance to overwrite /usr/sbin/sshd as example CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID NoNewPrivileges=yes ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr So I do see some issues with something like this, and I'll admit, they may not be easily solved. 1) This is 4 separate independent configuration directives (and leaves out things like SecureBits), not to mention it iterates over a list of capabilities. Setting all of them requires the admin/packager to understand the intersection of all of them, which may not be simple to apply correctly. (And you want to be careful with security controls in the hands of those not used to applying them correctly.) 2) It's also mixing specific implementation details (CapabilityBoundingSet) with more abstract concepts mapped to implementation details (NoNewPrivileges). That can leave the behavior confusing. 3) ReadOnlyDirectories also needs to be applied across submounts, which introduces complication to the system units depending on the filesystem layout on the administrator-configured machine - having security mechanisms be affected by this is not ideal. On the one hand, it's best to be explicit about what it's trying to do to secure the service, hence the many options to be set. On the other hand, it makes it much easier for the packager and admin to apply these sorts of service configurations correctly by mapping all options you'd need into more logical options that are easily explained. (Think of it as the same thing as exposing cgroupfs, vs exposing slices.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 23.07.2013 19:35, schrieb Bill Nottingham: Reindl Harald (h.rei...@thelounge.net) said: a httpd running with SElinux disabled or in permissive mode with the 4 lines below even after escalate to root privileges will hardly have a chance to overwrite /usr/sbin/sshd as example CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID NoNewPrivileges=yes ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr So I do see some issues with something like this, and I'll admit, they may not be easily solved. 1) This is 4 separate independent configuration directives (and leaves out things like SecureBits), not to mention it iterates over a list of capabilities. Setting all of them requires the admin/packager to understand the intersection of all of them, which may not be simple to apply correctly that was only an example the proposal was only for * ReadOnlyDirectories=/etc * ReadOnlyDirectories=/usr it is not 100%, nothing is that exept mount /usr read-only which needs a lot of work and has a high impact while the above costs nothing and can be easily overriden if needed hence i see no reason why a network aware service would write to /usr 2) It's also mixing specific implementation details (CapabilityBoundingSet) with more abstract concepts mapped to implementation details (NoNewPrivileges). That can leave the behavior confusing. again - the proposal was * ReadOnlyDirectories=/etc * ReadOnlyDirectories=/usr this doe snot need the packager understand much and additional things needs to be considered per service 3) ReadOnlyDirectories also needs to be applied across submounts, which introduces complication to the system units depending on the filesystem layout on the administrator-configured machine - having security mechanisms be affected by this is not ideal. needs is not really correct needs to be *fully* enabled a potential submount would not be read-only so what - without this the rest would not be too On the one hand, it's best to be explicit about what it's trying to do to secure the service, hence the many options to be set. On the other hand, it makes it much easier for the packager and admin to apply these sorts of service configurations correctly by mapping all options you'd need into more logical options that are easily explaine that's why i find ReadOnlyDirectories=/usr so dmaned useful signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 23.07.2013 19:54, schrieb Reindl Harald: 3) ReadOnlyDirectories also needs to be applied across submounts, which introduces complication to the system units depending on the filesystem layout on the administrator-configured machine - having security mechanisms be affected by this is not ideal. needs is not really correct needs to be *fully* enabled a potential submount would not be read-only so what - without this the rest would not be too and to be more clear * i want to protect /usr and what is instaleld via package-manager * submounts like bind-mounts in /usr/local are not read-only the latter should not because it is not installed by the package-manager and below /usr/local i have as example bind-mount structures for sftp-chroot it's perfect that they are not read-only signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 22.07.2013 16:37, schrieb Michael Scherer: Le lundi 22 juillet 2013 à 00:02 +0200, Reindl Harald a écrit : has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr http://www.freedesktop.org/software/systemd/man/systemd.exec.html additionally having the RPM database to accessable for network-services is fine, set for all listed below and reduces the attack surface InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/yum __ this would greatly reduce the impact of a possible root-exploit and IMHO make installing a rootkit hard to impossible while it is a good compromise to read-only /usr on a own partition without make system-administration via SSH harder I am not sure for /var/lib/rpm no webserver, mailserver, rsyslog or whatever needs to access the RPM db i would say for 99% of services it is pretty fine to disable access maybe exceptions for managament software For /usr and /etc, you need to be root to modify them most of the time if I am not wrong, and so if you are root, can you set them as being rw again?) AFAIK no or at least very difficult at all - systemd is the supervisor ( and anyway, even if root can change that, it may be sufficient to stop some automated worms, as I have already seen one that overwrite openssh binary, this would have been prevented) *that's the idea behind* exeptiopns: * trafficserver it touchs /etc/trafficserver at startup ReadOnlyDirectories=/usr is fine Seems like a bug in the software. It would prevent to have it run from a livecd. yes and no if you have not enabled cluster-support it should not need to touch it's config but it does including backups in form of _1 files, most of them can set RO for the ats user and it whines in the logs but is fine to start but because the cluster-thing you can't make /etc read-only as default * mediathomb refuses for whatever reason to start with read-only /etc ReadOnlyDirectories=/usr is fine Same as above that is for sure a bug signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr I think it's generally known by now that I don't like namespaces as a security mechanism. At best, this is duplicating SELinux policy with less transparency and worse tools. (The network services shouldn't be running as root in the first place.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Le lundi 22 juillet 2013 à 00:02 +0200, Reindl Harald a écrit : Hi has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr http://www.freedesktop.org/software/systemd/man/systemd.exec.html additionally having the RPM database to accessable for network-services is fine, set for all listed below and reduces the attack surface InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/yum __ this would greatly reduce the impact of a possible root-exploit and IMHO make installing a rootkit hard to impossible while it is a good compromise to read-only /usr on a own partition without make system-administration via SSH harder I am not sure for /var/lib/rpm. For /usr and /etc, you need to be root to modify them most of the time if I am not wrong, and so if you are root, can you set them as being rw again ? ) ( and anyway, even if root can change that, it may be sufficient to stop some automated worms, as I have already seen one that overwrite openssh binary, this would have been prevented ) exeptiopns: * trafficserver it touchs /etc/trafficserver at startup ReadOnlyDirectories=/usr is fine Seems like a bug in the software. It would prevent to have it run from a livecd. * mediathomb refuses for whatever reason to start with read-only /etc ReadOnlyDirectories=/usr is fine Same as above. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Mon, Jul 22, 2013 at 4:53 PM, Miloslav Trmač m...@volny.cz wrote: On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr I think it's generally known by now that I don't like namespaces as a security mechanism. At best, this is duplicating SELinux policy with less transparency and worse tools. Yeah I was about to write the same thing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Am 22.07.2013 16:53, schrieb Miloslav Trmač: On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr I think it's generally known by now that I don't like namespaces as a security mechanism. At best, this is duplicating SELinux policy with less transparency and worse tools. in general it is better to have more than one safety-net if it comes to security and there are environments where you simply can not enforce SElinux because they become unmaintainable (i have a few of them) (The network services shouldn't be running as root in the first place) privilege escalation i say here it is not much likely *but* a non-privileged process can break out at this did happen more than once in the past and will happen again, not every day but when it happens it's bad however, i enforced this the last few days, for the webserver even much more as for the other services and thought it maybe a good idea to share the result [Unit] Description=Apache Webserver After=network.service [Service] Type=simple EnvironmentFile=-/etc/sysconfig/httpd ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful Restart=always RestartSec=1 UMask=006 PrivateTmp=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/proc InaccessibleDirectories=/boot InaccessibleDirectories=/home InaccessibleDirectories=/root InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/yum InaccessibleDirectories=/var/spool InaccessibleDirectories=/usr/lib/dracut InaccessibleDirectories=/usr/lib/firmware InaccessibleDirectories=/usr/lib/modprobe.d InaccessibleDirectories=/usr/lib/modules InaccessibleDirectories=/usr/lib/modules-load.d InaccessibleDirectories=/usr/lib/sysctl.d InaccessibleDirectories=/usr/lib/tmpfiles.d InaccessibleDirectories=/usr/lib/udev [Install] WantedBy=multi-user.target signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Mon, Jul 22, 2013 at 04:53:36PM +0200, Miloslav Trmač wrote: On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr I think it's generally known by now that I don't like namespaces as a security mechanism. At best, this is duplicating SELinux policy with less transparency and worse tools. Namespaces really aren't duplicating SELinux policy, they are working in a complementary fashion. There is clear value in having multiple layers of security defence because things do fail for any number of reasons. In the SELinux case, we all know many admins will set it to permissive mode, at which point your second line of defence becomes your primary line of defence. Namespaces don't offer as much protection as SELinux MAC, but they can offer more protection than plain DAC control in certain usage scenarios. (The network services shouldn't be running as root in the first place.) No argument there, but even if something is running as non-root there is the potential for privilege escalation through security flaws in some thing that they use. In such a scenario having a separate filesystem namespace which has made certain areas read-only may well stop the exploit. There's obviously a cost/benefit tradeoff to be made, and we may consider that just making /etc /var readonly has not got enough benefit, but just dismissing use of namespaces out of hand without doing such evaluation is really not helpful. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposal: ReadOnlyDirectories /etc and /usr for network-services
Hi has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr http://www.freedesktop.org/software/systemd/man/systemd.exec.html additionally having the RPM database to accessable for network-services is fine, set for all listed below and reduces the attack surface InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/yum __ this would greatly reduce the impact of a possible root-exploit and IMHO make installing a rootkit hard to impossible while it is a good compromise to read-only /usr on a own partition without make system-administration via SSH harder __ currently i am in prodcution with it for the following services most of them real production (customer-services) and a few on home-servers or even not available in the Fedora repos * asterisk * dbmail * dhcpd * dnsmasq * dovecot (running as IMAP/POP3 proxy and SASL) * hostapd * httpd * hylafax * iaxmodem * mailgraph * mpd * mpdscribble * mysqld * named * netatalk * ntpd * open-vm-tools * openvpn * postfix * prosody * pulseaudio (systemwide) * pure-ftpd * rsyslog * smbd * smokeping * unbound * vnstat * xinetd (TFTP) __ exeptiopns: * trafficserver it touchs /etc/trafficserver at startup ReadOnlyDirectories=/usr is fine * mediathomb refuses for whatever reason to start with read-only /etc ReadOnlyDirectories=/usr is fine signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
Le Lun 22 juillet 2013 00:02, Reindl Harald a écrit : Hi has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr It would be very nice if write-protection of FHS-defined RO directories was applied by default, except for the software updater or during explicit maintenance operations. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Jul 22, 2013 at 04:53:36PM +0200, Miloslav Trmač wrote: On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr I think it's generally known by now that I don't like namespaces as a security mechanism. At best, this is duplicating SELinux policy with less transparency and worse tools. Namespaces really aren't duplicating SELinux policy, they are working in a complementary fashion. There is clear value in having multiple layers of security defence because things do fail for any number of reasons. The returns to additional layers enforcing the same policy are rapidly diminishing, though. We already have DAC permissions, and MAC policy, and a third layer is being proposed. Why not have four or ten? We have to stop somewhere. (The network services shouldn't be running as root in the first place.) No argument there, but even if something is running as non-root there is the potential for privilege escalation through security flaws in some thing that they use. In such a scenario having a separate filesystem namespace which has made certain areas read-only may well stop the exploit. If I am able to escalate to root privileges, I can just switch back to the system namespace using setns(2), so the protection doesn't actually exist. So we're talking about limited circumstances where the attacker can modify files and not execute code, or where the attacker is root but not CAP_SYS_ADMIN (or whatever it is). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: ReadOnlyDirectories /etc and /usr for network-services
On Mon, Jul 22, 2013 at 06:37:01PM +0200, Miloslav Trmač wrote: On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Jul 22, 2013 at 04:53:36PM +0200, Miloslav Trmač wrote: On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.rei...@thelounge.net wrote: has anybody considered to put the following as default in systemd-units of network services? cross-posting to users-list intented because i think it is a good idea to bring it to a broader userbase! ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr I think it's generally known by now that I don't like namespaces as a security mechanism. At best, this is duplicating SELinux policy with less transparency and worse tools. Namespaces really aren't duplicating SELinux policy, they are working in a complementary fashion. There is clear value in having multiple layers of security defence because things do fail for any number of reasons. The returns to additional layers enforcing the same policy are rapidly diminishing, though. We already have DAC permissions, and MAC policy, and a third layer is being proposed. Why not have four or ten? We have to stop somewhere. Counting layers of protection is not a helpful way to make decisions on usage of security. As I said in my previous mail you should evaluate the benefits of any proposed technology, and not rule it out simply because we already have other options. (The network services shouldn't be running as root in the first place.) No argument there, but even if something is running as non-root there is the potential for privilege escalation through security flaws in some thing that they use. In such a scenario having a separate filesystem namespace which has made certain areas read-only may well stop the exploit. If I am able to escalate to root privileges, I can just switch back to the system namespace using setns(2), so the protection doesn't actually exist. So we're talking about limited circumstances where the attacker can modify files and not execute code, or where the attacker is root but not CAP_SYS_ADMIN (or whatever it is). Using setns() requires opening a FD to /proc/$PID/ns/mount for a $PID in the target namespace. If putting the service in a separate mount namespace, it is easy to also set CLONE_PID, at which point the /proc/$PID/ns files for any other process are no longer accessible. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
