On: The Insecurity of Debian

[EvanAnderson]

I always pushed back hard on vendors who wanted me to disable SELinux on my RHEL boxes. It's unacceptable to disable default OS security protections to make an application function. It's no different than demanding an app run as root.

[stevekemp → EvanAnderson]

Indeed, disabling SELinux is like following instructions for PHP applications and running "chmod -R 777 /var/www".

I used to work at a payment provider and we had to deal with lots of monitoring and security stuff. Some of it was (obviously) busywork and needless checkbox filing, but other parts were genuinely useful. Setting up systems was tedious and difficult, but ultimately worthwhile and necessary.

[bigfatkitten → stevekemp]

> Indeed, disabling SELinux is like following instructions for PHP applications and running "chmod -R 777 /var/www".

HP at one point said to "chmod -R 777 /sbin" in their ArcSight install documentation, and that's a 'security' product.

[01HNNWZ0MV43FF → EvanAnderson]

Oops

-- A developer whose app needs to run as root (for a well-documented reason, and with a tight systemd sandbox hiding most of the filesystem from it)

[NewJazz → 01HNNWZ0MV43FF]

If it is running as root, can't it just manipulate its mount namespace at will? Mount devtmpfs, then mount user partitions.

[hackernudes → NewJazz]

I believe one can use "capabilities" and seccomp to lock down a superuser process.

[superb_dev → NewJazz]

Systemd can put it in its own namespaces, like a container

[kbolino → EvanAnderson]

It's worse, actually. Root can still be confined under SELinux with a good policy.