Discussion:
Proposal: ReadOnlyDirectories /etc and /usr for network-services
(too old to reply)
Reindl Harald
2013-07-21 22:02:02 UTC
Permalink
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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130722/da6bd0e0/attachment.sig>
Michael Scherer
2013-07-22 14:37:39 UTC
Permalink
Post by Reindl Harald
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 )
Post by Reindl Harald
* 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.
Post by Reindl Harald
* mediathomb
refuses for whatever reason to start with read-only /etc
"ReadOnlyDirectories=/usr" is fine
Same as above.
--
Michael Scherer
Reindl Harald
2013-07-22 14:45:42 UTC
Permalink
Post by Michael Scherer
Post by Reindl Harald
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
Post by Michael Scherer
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
Post by Michael Scherer
( 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*
Post by Michael Scherer
Post by Reindl Harald
* 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
Post by Michael Scherer
Post by Reindl Harald
* mediathomb
refuses for whatever reason to start with read-only /etc
"ReadOnlyDirectories=/usr" is fine
Same as above
that is for sure a bug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130722/3d16400e/attachment.sig>
Miloslav Trmač
2013-07-22 14:53:36 UTC
Permalink
Post by Reindl Harald
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
drago01
2013-07-22 15:02:26 UTC
Permalink
Post by Miloslav Trmač
Post by Reindl Harald
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.
Reindl Harald
2013-07-22 15:01:20 UTC
Permalink
Post by Miloslav Trmač
Post by Reindl Harald
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)
Post by Miloslav Trmač
(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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130722/405d734b/attachment.sig>
Daniel P. Berrange
2013-07-22 16:22:57 UTC
Permalink
Post by Miloslav Trmač
Post by Reindl Harald
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.
Post by Miloslav Trmač
(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 :|
Miloslav Trmač
2013-07-22 16:37:01 UTC
Permalink
Post by Daniel P. Berrange
Post by Miloslav Trmač
Post by Reindl Harald
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.
Post by Daniel P. Berrange
Post by Miloslav Trmač
(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
Daniel P. Berrange
2013-07-22 16:43:54 UTC
Permalink
Post by Miloslav Trmač
Post by Daniel P. Berrange
Post by Miloslav Trmač
Post by Reindl Harald
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.
Post by Miloslav Trmač
Post by Daniel P. Berrange
Post by Miloslav Trmač
(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 :|
Reindl Harald
2013-07-22 16:53:57 UTC
Permalink
Post by Miloslav Trmač
Post by Daniel P. Berrange
Post by Miloslav Trmač
Post by Reindl Harald
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
Post by Miloslav Trmač
Post by Daniel P. Berrange
Post by Miloslav Trmač
(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
Post by Miloslav Trmač
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130722/ed5371f2/attachment.sig>
Bill Nottingham
2013-07-23 17:35:53 UTC
Permalink
Post by Reindl Harald
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
Reindl Harald
2013-07-23 17:54:41 UTC
Permalink
Post by Bill Nottingham
Post by Reindl Harald
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
Post by Bill Nottingham
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
Post by Bill Nottingham
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
Post by Bill Nottingham
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130723/46f2c1c5/attachment.sig>
Reindl Harald
2013-07-23 18:23:18 UTC
Permalink
Post by Reindl Harald
Post by Bill Nottingham
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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130723/eed89d65/attachment.sig>
drago01
2013-07-25 15:57:50 UTC
Permalink
Post by Reindl Harald
Post by Miloslav Trmač
Post by Daniel P. Berrange
Post by Miloslav Trmač
Post by Reindl Harald
has anybody considered to put the following as default in
systemd-units of
Post by Reindl Harald
Post by Miloslav Trmač
Post by Daniel P. Berrange
Post by Miloslav Trmač
Post by Reindl Harald
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
Post by Miloslav Trmač
Post by Daniel P. Berrange
Post by Miloslav Trmač
(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
Post by Miloslav Trmač
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/a0c14b2e/attachment.html>
Reindl Harald
2013-07-25 16:36:58 UTC
Permalink
Post by Reindl Harald
in theory yes
practically a exploit is not that easy like fire
a bundle of commands as root like a script
Post by Miloslav Trmač
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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/e942d296/attachment.sig>
drago01
2013-07-25 18:31:29 UTC
Permalink
Post by Reindl Harald
Post by Reindl Harald
in theory yes
practically a exploit is not that easy like fire
a bundle of commands as root like a script
Post by Miloslav Trmač
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.
Reindl Harald
2013-07-25 18:39:36 UTC
Permalink
Post by drago01
Post by Reindl Harald
Post by Reindl Harald
in theory yes
practically a exploit is not that easy like fire
a bundle of commands as root like a script
Post by Miloslav Trmač
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
Post by drago01
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
Post by drago01
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/a3938755/attachment.sig>
drago01
2013-07-25 18:51:09 UTC
Permalink
Post by Reindl Harald
Post by drago01
Post by Reindl Harald
Post by Reindl Harald
in theory yes
practically a exploit is not that easy like fire
a bundle of commands as root like a script
Post by Miloslav Trmač
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.
Post by Reindl Harald
Post by drago01
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
Post by drago01
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.
Post by Reindl Harald
in my case these are over more than 10 years grown environments
Irrelevant.
Post by Reindl Harald
responsible for over 600 domains which was migrated from MacOSX
to Fedora years ago,
Irrelevant.
Post by Reindl Harald
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.
drago01
2013-07-25 19:06:28 UTC
Permalink
Post by drago01
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"
Reindl Harald
2013-07-25 19:10:17 UTC
Permalink
Post by drago01
Post by drago01
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
Post by drago01
"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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/e776a4a1/attachment-0001.sig>
Reindl Harald
2013-07-25 19:01:59 UTC
Permalink
Post by drago01
Post by Reindl Harald
*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
Post by drago01
Post by Reindl Harald
in my case these are over more than 10 years grown environments
Irrelevant
for you...........
Post by drago01
Post by Reindl Harald
responsible for over 600 domains which was migrated from MacOSX
to Fedora years ago,
Irrelevant
for you............
Post by drago01
Post by Reindl Harald
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/6537c58f/attachment-0001.sig>
Miloslav Trmač
2013-07-25 19:26:46 UTC
Permalink
Post by Reindl Harald
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
Reindl Harald
2013-07-25 19:36:08 UTC
Permalink
Post by Miloslav Trmač
Post by Reindl Harald
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
Post by Miloslav Trmač
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?"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/2997aab9/attachment.sig>
Nicolas Mailhot
2013-07-22 16:10:25 UTC
Permalink
Post by Reindl Harald
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
Reindl Harald
2013-07-22 17:28:12 UTC
Permalink
Post by Nicolas Mailhot
Post by Reindl Harald
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130722/62d901de/attachment-0001.sig>
Lennart Poettering
2013-07-25 17:48:37 UTC
Permalink
Post by Reindl Harald
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.
Post by Reindl Harald
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.
Reindl Harald
2013-07-25 18:01:32 UTC
Permalink
Post by Lennart Poettering
Post by Reindl Harald
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
Post by Lennart Poettering
Post by Reindl Harald
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
Post by Lennart Poettering
"ReadOnlyDirectories=/etc /usr" simply encodes the semantics that we
/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
Post by Lennart Poettering
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
Post by Lennart Poettering
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/a866ae86/attachment.sig>
Rahul Sundaram
2013-07-25 19:00:08 UTC
Permalink
Hi
Post by Lennart Poettering
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130725/87c43e22/attachment.html>
Continue reading on narkive:
Loading...