What chroot() is really for
Posted Oct 5, 2007 4:04 UTC (Fri) by wahern
In reply to: What chroot() is really for
Parent article: What chroot() is really for
Why should they look at SELinux at all? The "least cost avoider" regarding software robustness is the developer, not the user. In other words, why do a million administrators have to lock down applications when the developer could have written the application better to begin with. Why are people arguing for solutions that put the onus on the user, AT THE EXPENSE of solutions which the developer can implement? I don't mean to say that SELinux shouldn't be used, but with limited time and resources, it seems to make sense to me to emphasize the measures developers can take.
Also, if SELinux were actually easy to use, why don't Linux distributions ship with policies that don't frustrate users? That's not to say it can't be done. It's only evidence that it can't be done well, yet. In my opinion, there's some key abstraction missing which, when discovered, will likely make MAC schemes more intuitive, automagically adaptable to the environment, and much more common place than they are. We just aren't there yet. The evolution of Unix tells us that only those interfaces which have proven themselves become standardized across platforms. For my money, compartmentalized environments a la BSD jails/Solaris Zones seem to be the wave of the future, even if personally I'd like to see MAC schemes become the norm.
Lost in this whole debate is something called portability. As a developer, I'm not going to write software with the expectation that the user will run it in UML or a BSD jail. Fact is, chroot is available on every single Unix system, with identical semantics. I'll write my software as best I can so that diligent users can run software in a jail, but just because others can or would isn't reason to persuade me not to use chroot.
to post comments)