Re: [gentoo-hardened] hardened workstation - is that worth it?

[Javier Martínez]

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 <janklodvan@×××××.com>:
> 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?
>
>