| |||||||||||
Re: non C based environments can have problemsRe: non C based environments can have problemsPosted Jan 20, 2007 22:09 UTC (Sat) by scottt (subscriber, #5028)In reply to: Re: non C based environments can have problems by pvaneynd Parent article: LCA: How to improve Debian security
On my fedora system an implementation of the java virtual machine is labeled with the type "java_exec_t":
Clearly sbcl want its own selinux policy module which grants it all the memory mapping priviledges it wants?
(Log in to post comments)
Re: non C based environments can have problems Posted Jan 22, 2007 0:59 UTC (Mon) by dododge (subscriber, #2870) [Link] If I understand the situation with sbcl, SELinux isn't even really a problem. sbcl's troubles come from other security measures aimed at buffer overflows, such as address space randomization and non-executable pages. As pvaneynd says, some old programs make assumptions about the way Unix is implemented, above and beyond what the standards guarantee. The security measures may be within the scope of the standard but they break those old assumptions and some programs just can't handle it. Emacs Lisp is another one like this. I assume it's still using tagged pointers, which are efficient from a practical standpoint but a total abomination from a portability standpoint. A quick glance at its lisp.h suggests that it's using unions in ways that C says are undefined -- but will work due to the way most C compilers just happen to be implemented.
|
|||||||||||