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
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.
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
On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.reindl@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
Am 22.07.2013 16:53, schrieb Miloslav Trmač:
On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.reindl@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
On Mon, Jul 22, 2013 at 4:53 PM, Miloslav Trmač mitr@volny.cz wrote:
On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald h.reindl@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.
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.reindl@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
On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange berrange@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.reindl@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
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 berrange@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.reindl@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
Am 22.07.2013 18:37, schrieb Miloslav Trmač:
On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange berrange@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.reindl@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
Reindl Harald (h.reindl@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
Am 23.07.2013 19:35, schrieb Bill Nottingham:
Reindl Harald (h.reindl@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.
- 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
- 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
- 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
Am 23.07.2013 19:54, schrieb Reindl Harald:
- 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
On Monday, July 22, 2013, Reindl Harald h.reindl@thelounge.net wrote:
Am 22.07.2013 18:37, schrieb Miloslav Trmač:
On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange berrange@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.reindl@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.
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
On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.reindl@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.
Am 25.07.2013 20:31, schrieb drago01:
On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.reindl@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
On Thu, Jul 25, 2013 at 8:39 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 25.07.2013 20:31, schrieb drago01:
On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.reindl@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.
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
On Thu, Jul 25, 2013 at 9:01 PM, Reindl Harald h.reindl@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"
Am 25.07.2013 21:06, schrieb drago01:
On Thu, Jul 25, 2013 at 9:01 PM, Reindl Harald h.reindl@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
On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.reindl@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
Am 25.07.2013 21:26, schrieb Miloslav Trmač:
On Thu, Jul 25, 2013 at 6:36 PM, Reindl Harald h.reindl@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?"
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,
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
On Mon, 22.07.13 00:02, Reindl Harald (h.reindl@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
Am 25.07.2013 19:48, schrieb Lennart Poettering:
On Mon, 22.07.13 00:02, Reindl Harald (h.reindl@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
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
-
Bill Nottingham -
Daniel P. Berrange -
drago01 -
Lennart Poettering -
Michael Scherer -
Miloslav Trmač -
Nicolas Mailhot -
Rahul Sundaram -
Reindl Harald