more about vista security
While reading the discussion of Vista security on Bruce Schneier's blog it occurred to me that comparing the issues of DRM that face MS with the issues faced by SE Linux developers provides some benefits.
SE Linux is designed to enable the owner of a computer to effectively enforce security policies to protect their system integrity and the confidentiality of their data. Some of the SE Linux users (military users) use all the available features, but most people only use the targeted policy which provides a sub-set of the system integrity and data confidentiality protections that are available to give a greater ease of use.
Fedora and Red Hat Enterprise Linux ship with the SE Linux targeted policy enabled by default. This policy is not something that most users notice. The main program that is commonly used which might have an issue with the default SE Linux policy is Apache. Fedora and RHEL systems that do not run Apache (which is most of them) can run SE Linux with almost no costs.
setsebool -P httpd_disable_trans 1It seems clear to me that there is no good reason for disabling SE Linux by default. There are reasons for running a particular daemon in the unconfined_t domain via the FOO_disable_trans boolean. EG to run Apache without restrictions you would type the above commands.
/etc/init.d/httpd restart
In spite of the SE Linux targeted policy being so easy to use, the fact that it prevents certain daemon compromises from allowing immediate control of the system, and also prevents some kernel exploits from working, there are still some people who turn it off when installing Fedora and RHEL systems and advise others to do so.
Given this great fear of some people to use a technology that is specifically designed for their own benefit I find it difficult to imagine that any users will be inclined to accept the MS DRM technology that is specifically designed to go against their interests.
ESR claims that the 64bit transition is the critical period for Linux to move on the desktop. While he makes many interesting observations I don't find his argument convincing. Firstly current P4 CPUs with PAE can handle significantly more than 4G of RAM (64G is possible now). Secondly it's quite possible to run a 64bit kernel with 32bit applications, this means that you can use a 64bit kernel to access >64G of RAM with each 32bit application getting direct access to something slightly less than 4G of virtual memory. As ESR's point seems based on total system memory the 4G per application doesn't seem to be an issue. As an aside the only applications I've used which could benefit from >4G are database servers (in the broadest interpretation - consider an LDAP server as a database) and JVM environments. Again it would not be difficult to ship an OS with mostly 32bit code that has a 64bit kernel, JVM, and database servers.
I hope that Vista will be a good opportunity for mass transition to Linux. Vista offers little that users desire, many things that will hurt them, and is expensive too!
With Vista you pay more for the OS and more for the hardware (Vista has the usual excessive Windows hardware requirements plus the extra hardware for TPM encryption) without providing anything substantial in return.
What I want to see next is support for Security Enhanced X to protect desktop environments against hostile X clients. This will make a significant difference to the security of Linux desktop environments and provide another significant benefit for choosing Linux over Windows. While MS is spending their effort in making their OS act against the best interests of the users we will keep making Linux enforce the access controls that users need to protect their systems. Hopefully Linux users will choose to use SE-X, but if they don't they are given the freedom to make that choice - unlike the poor sods who use Windows.
4 comments:
I would disable SELinux on any system I installed at the moment, for one good reason: I don't want stuff running on my system that I don't yet understand the details of, and I don't currently have the time or inclination to learn about SELinux. Thus, when it breaks, I wouldn't have the knowledge to fix it or even know where to start.
Do you understand how init works? What about login? Most sys-admins don't really understand either.
A modern OS is too complex to understand all details of everything, fortunately such understanding is not required. In my blog post I demonstrated how to run a daemon unconfined - this is the main thing you need to know to solve problems with the targeted policy.
"Do you understand how init works? What about login?"
Why yes, I do. :)
"A modern OS is too complex to understand all details of everything, fortunately such understanding is not required."
I didn't say that I needed to understand all details of everything. I said I want to understand enough to fix it when it breaks. Just knowing how to turn it off doesn't tell me how to fix it, just how to bypass it.
I agree with you in principle that having more restrictions on what daemons can do seems like a good idea.
You do understand init and login?
Which process opens the file handle for the virtual console for a VC login? What processes manage the utmp file? Most sys-admins don't know the answer to these questions.
How and when does init get restarted?
In what ways is init different to other processes?
A Unix system is very complex, most people who think that they understand it really don't. Proof of this is the debates I have with daemon authors regarding what their programs do - when writing SE Linux policy I discover daemons doing inappropriate things and then the hard part is to convince the author that such things are done (they don't understand their own code) and that they shouldn't be done (they don't understand how to design an application to be secure and fail in a sensible manner when things go wrong).
A classic example is all the daemons that use config files under /root. If you change application config files for the root user you may break daemons due to bad design.
Post a Comment