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@xxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote: > >> > has anybody considered to put the following as default in systemd-units of > >> > network services? cross-posting to users-list intented because i think it > >> > is a good idea to bring it to a broader userbase! > >> > > >> > ReadOnlyDirectories=/etc > >> > ReadOnlyDirectories=/usr > >> > >> I think it's generally known by now that I don't like namespaces as a > >> security mechanism. At best, this is duplicating SELinux policy with > >> less transparency and worse tools. > > > > Namespaces really aren't duplicating SELinux policy, they are working > > in a complementary fashion. There is clear value in having multiple > > layers of security defence because things do fail for any number of > > reasons. > > The returns to additional layers enforcing the same policy are rapidly > diminishing, though. We already have DAC permissions, and MAC policy, > and a third layer is being proposed. Why not have four or ten? We > have to stop somewhere. Counting layers of protection is not a helpful way to make decisions on usage of security. As I said in my previous mail you should evaluate the benefits of any proposed technology, and not rule it out simply because we already have other options. > >> (The network services shouldn't be running as root in the first place.) > > > > No argument there, but even if something is running as non-root there is > > the potential for privilege escalation through security flaws in some > > thing that they use. In such a scenario having a separate filesystem > > namespace which has made certain areas read-only may well stop the > > exploit. > > If I am able to escalate to root privileges, I can just switch back to > the system namespace using setns(2), so the protection doesn't > actually exist. So we're talking about limited circumstances where > the attacker can modify files and not execute code, or where the > attacker is root but not CAP_SYS_ADMIN (or whatever it is). Using setns() requires opening a FD to /proc/$PID/ns/mount for a $PID in the target namespace. If putting the service in a separate mount namespace, it is easy to also set CLONE_PID, at which point the /proc/$PID/ns files for any other process are no longer accessible. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
