On 29/07/09 06:47, Alon Bar-Lev wrote: > Well, > I do not understand you guys. > > If you think SELinux is so great, why do you need chroot? > It is like you put some money in safe, and then put the safe into > another safe, it never ends... Why only two safe, let's put another > safe... > I know that this is the approach many of security advisors use, but I > never could have found the logic. > If you want to keep your money safe use a single safe and select the > strongest one.
I understand partly your logic. But unfortunately, this is what most security crackers hope for. They look for every possibility to get an opening into a network or server, to gain root access and enable the box they got access to for further usage. To defend yourself from a possibility of a break in, you need to take all possibilities available in use. If not, you are weaker than other solutions, and your setup will be more attractive to those trying to crack into your server. This is nothing new, this is how the daily life is. Sooner or later, OpenVPN will be more attractive in general for being cracked, when other solutions gets more and more secured. Sooner or later, OpenVPN will get the storm. If we are ahead of that storm by promoting and recommending all possible security features available, implementing them, the damage after such a storm might not be as big as it can be without taking advantage of all security measures available. And another thing you do not take into consideration, is that in your argument you take it for granted that OpenVPN do not have any security related bugs, e.g. a buffer overflow which can be misused by carefully hand crafted network packages, which is unexpected. It can even be a flaw inside OpenSSL (which is also not that uncommon). With SELinux you limit much more than what chroot() + setuid() can do alone. But as I said earlier, non of these calls exclude any other. > And final note regarding the iproute wrapper. > It is a *WRAPPER*, if I needed top secured implementation I would have > created a daemon listening to network change requests using unix > domain sockets, wrap this up in SELinux profile, and implementing a > logic that allows only changes to tap/tun interface with specific > attributes, and allowing routing table update with specific details. > Then add a wrapper that uses the unix domain socket in order to access > the daemon. OpenVPN will use the wrapper so it needs no special > privilege. The daemon validates what SELinux or any other security > product cannot validate: Network configuration changes. All done > within a valid and separate context. This is actually even a much better idea than a wrapper, seriously! Wrappers, and especially wrappers with sudo access (or even worse, the setsuid bit set on the file) are prune to be cracked and misused. As the matter of fact, I've gotten a flaw demonstrated which managed, through a overflow bug, to write a nicely crafted crontab entry which then caused the crond to core dump on execution of that entry. But when that happened, you had a setsuid binary in /tmp ... which actually was a copy of a shell. But it required SELinux to be either to be disabled or be in Permissive mode (logging only). > As I wrote earlier, most of OpenVPN configurations need to execute > iproute also during session. For example, if you like to connect two > sites, your super SELinux secured solution will work only at one site. Yes! And WITH SELinux, it will still be able to run iproute or whatever else the configuration requires - in a safer and more controlled regime. But it will not only work on one site. It will work wherever SELinux is properly configured and implemented. In fact, it will not even break the OpenVPN functionality if you run a SELinux enabled OpenVPN on a kernel without SELinux enabled, you will just miss that extra layer of security. Security is not about picking the best solution of several options. Security is about combining the best of all solutions together. kind regards, David Sommerseth
