Why are the bit root-suid applications a risk in the point of view of security? The X server is a root-setuid binary that can't be assured from the point of view of posix capabilities for example, the reason is clear one process that has only CAP_SYS_RAWIO capability could make raw writing in /dev/mem!!!. Before the filesystem capabilities one process with only CAP_SYS_RAWIO and the others restricted could add all others capabilities missing by simply searching the cap_bset in their system.map and writting 0xFFFFFEFF in it through /dev/mem. With this hack he has CAP_SYS_SUID CAP_SYS_SGID, CAP_DAC_OVERRIDE etc..., now with the filesystem capabilities probably you could do the same by writting in the task_struct of the process. Xorg is worst than a normal setuid program, ping for example could be assured granting only CAP_NET_RAW, with this privilege ping can't own the rest of the system. Xorg can't be assured, it needs CAP_SYS_RAWIO and CAP_DAC_OVERRIDE between others, enough to write /dev/mem).
Xorg adds one level of complexity unaceptable from a security view point, it's something like sendmail, how could you make sendmail more secure?, rewritting it from 0!!!! Xorg was not designed to be secure, only to networking. Patches has been added (as xace extensions) to make it a bit more secure, but it stills insecure (if you dress a monkey to be saw as a human, it stills being monkey!!). Xorg mmaps video memory through /dev/mem and I think that the way it does it is which make it incompatible with PaX mprotect restrictions (pax author could tell you more), so is a problem of Xorg, not PaX does simply does his job kill Xorg. Complexity and security are enemies, and if complexity is added to a bad design then switch off. In my opinion having 3 or 300 holes is irrelevant from a security view point, with only one is enough!. Any programmer with a bit of known of assembly could make exploits, and as phrack made in one of his articles, one great programmer with deep knowledge of memory management and PaX could even defeat it. 2008/11/25 Jan Klod <[EMAIL PROTECTED]>: > On Tuesday 25 November 2008 19:58:42 RB wrote: >> KDE (and to a lesser extent X) pretty much nullifies most application >> isolation efforts you're going to make. > > Actually, that sound like there is practically no way to keep networked > workstation really secure. Sure, is not trivial to gain root access through > software bugs (interesting, how many list member would be able to do it?), > but no one running X can claim, he has absolutely secure system, which can't > fail him regardless to who is the hacker. > Furthermore, the system is said to be only as secure as the weakest part, so > making hardened server will only slow down attacks and, at most, ensure > server stability. Still, if there is someone ready to attack servers end > clients (which ones will almost always have X running), the way can be open. > > Can someone explain how would it happen, the exploitation of buffer overflow > in X? How would attacker gain access to X bug most importantly? What are > those ways for other apps? Always different? > And have there been any efforts to make PaX enabled X? > > Personally, I think, the best way would be using firewall to allow only the > most necessary addresses, which point to trusted services (mail,sftp,...). > That said, web browsing is cut off. > > As a conclusion of what I have read this far I can state: hardened OS is > useless for non-server. Would that be too much? Well, I think, in a "black > and white" no. (later is a discussion of what is better: to have 3 holes or > 300) > > Comments? > >
