>> * Are the r/w accesses to the BIOS and to the first page really >> necessary, or could they be eliminated or at least made optional? I >> would be willing to trade in e.g. some autoconfiguration features >>like >> DDC for the additional security! > >All /dev/mem mappings appear to be r/w simply because the same file >descriptor is used. That does not mean XFree86 writes into all such >mappings.
Wrong, three times:
* Only very few mmap's use a permanently opened fd. According to the strace, most perform the open, a single mmap, and the close in short succession.
* Even if you use a single fd opened permanently for r/w, the flags for mmap allow a r/o mmap of a r/w fd (and grsec lets them pass).
* There are also r/o mmap's in Xfree's strace, several of them. So some people did their homework...
Also, wrong attitude and wrong design principles:
* Programs should *never ever* request or hold more priviledges than they absolutely need to do their job. If you have no intention to write to it, open it r/o!
* If Xfree crashes badly (notebooks have non-ECC RAM and run hot), is broken into (a few megabytes of code without a single buffer overflow?), or is poisoned by making it load a malicious dynamic module, I *don't want* it to have write access to the system's interrupt vector or anything similar. Period.
I run a static linux kernel (compiled without the whole module loading mechanism) as a precaution against backdoors, and I don't want to have any other program which loads code pieces dynamically and in fact runs with kernel priviledges (r/w access to the interrupt vector is most important and sufficient to backdoor the kernel).
This is especially true for Xfree, which is the only piece of code on my system which runs as root without nonexec stack protection (I'm still waiting for the xfree configuration option to statically link in it's modules instead of dynamically loading them).
* Besides security, this increases readability (because somebody reading or debugging your code can make the assertion "ahh, he will be only reading what he just opened/mmapped") and might in general allow additional optimizations and efficiency on the kernel side (e.g. cacheable/noncachable or shared/nonshared settings, especially on multiprocessors). The more exactly we know what a program really wants to do, the better we can prepare for it.
>> * Could the Xfree team and the grsec team please coordinate their >> efforts? I need both! > >No, you don't.
Could you please let *me* decide what level of protection I want and how much I trust the applications I run (not only Xfree)?
I'm a teacher for programming and networking in a technical high school. I've grades, exams and the like on this notebook, and this notebook is regularly connected to the school's network, sharing files both ways and offering services. I also regularly receive Email with code from pupils, or visit their web pages. This is a primary target, any level of protection is welcome.
>> * Is there a list of Xfree drivers which work fine with grsec (i.e.
>> perform r/w mmap's only to the PCI address space and the >>framebuffer)?
>> This information would be helpful for future hardware investments,
>> especially on security-sensitive systems...
>
>The grsec folk need to do their homework more thouroughly. In >particular,
>they should look at what some of the *BSDs have been doing for years in
>this regard (and how XFree86 gets around such nonsense).
>
>grsec and facilities like it are based on a false premise: that 'root'
>can be broken into is sufficient justification to limit what 'root' can
>do, or even to remove entire system functions.
>
>The security pedants should instead concentrate their efforts on how
>'root' can be broken into.
I disagree:
* The "almighty root" principle will be replaced by fine-grained, capability-based security concepts sooner or later (hopefully sooner). Xfree will get the cap to do PCI I/O and access the framebuffer. It will definitely not get the cap to map arbitrary RAM areas, and it will most likely be generally impossible to map ROM areas for writing. So Xfree should be prepared...
* I don't trust a single inside/outside security concept like "root"/"nonroot". History has shown just too often that this promise doesn't hold. I prefer to have *dozens* of barriers against intruders: A firewall, a nonexec stack, chroot jails, paranoid permissions, a static kernel, and several other minor precautions. It minimizes the effect of single security holes (which will always happen), and it maximizes the chance that an intruder will give up or hit some tripwire which alerts me before he really gets almighty power (kernel level).
* If everything which needs to do "something important" gets almighty root priviledges, we end up with hundreds of servers which run as root and applications which are started setuid root or sudo'ed. Consequently, the volume of critical code increases, the probability of holes in root code increases, the damage they are allowed to cause increases, and the security of root decreases.
Hence, the concept of "all rights to root, none to the others, and let's try to protect root" leads to a contradiction in itself.
-- DI. Dr. Klaus Kusche Email: [EMAIL PROTECTED] WWW: http://members.inode.at/kusche Phone @ home: +43 7234 83894 Phone @ work: +43 732 673368 0 Private address: Buchenweg 15, A-4100 Ottensheim, Austria Office address: HTBLA Leonding, Limesstr. 12-14, 4060 Leonding, Austria or HTBLA Traun, Holzbauernstr. 20, 4050 Traun, Austria
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
