| |||||||||||||
Re: non C based environments can have problemsRe: non C based environments can have problemsPosted Jan 19, 2007 21:03 UTC (Fri) by dododge (subscriber, #2870)In reply to: non C based environments can have problems by pvaneynd Parent article: LCA: How to improve Debian security
For example sbcl (a Common Lisp environment that compiles directly to native code) does have quite a bit of problems with all these new 'security' measures, Looking at the referenced page, this doesn't seem to be a problem with the security measures so much as a rather serious design flaw in sbcl. mmap never guarantees you will get the address you ask for. Granted sbcl may have been getting lucky up to now, but it never should have required a specific mapping in the first place. I say that as someone who has written many applications working with anything from a few megabytes to a hundred gigabytes of elaborate memory-mapped data structures, including situations where multiple threads and processes are using the data simultaneously at different mapped addresses. This sort of thing is not a problem if you design it in from the start like you're supposed to do.
(Log in to post comments)
Re: non C based environments can have problems Posted Jan 19, 2007 21:29 UTC (Fri) by pvaneynd (subscriber, #898) [Link] sbcl is older then you might think, it is based on cmu which started life on the pdp10, see the cmucl history. So it does things a little different from normal C programs.
Yet I fully agree that cmucl/sbcl are way "out there" on the compatibility side of things, doing stuff that is more tradition then standard. Not only the memory management is strange, they also catch SIGSEGV and friends to handle errors. They use breakpoints on themselves to do debugging and error signaling, they use write-barriers by using mprotect on pages. This has the effect that if the kernel people slow the rate at which we can accept, handle and returns from normally fatal exceptions we slow down or get random errors (like fpu flag corruption). Even libc changes can hurt us: when errno was changed from an integer variable to a macro we had to handle that with some difficulty. Changing the image to PIC is on the todo list, but with the register-starved x86 architecture nobody seems to want to dedicate a register for handling the offset for the previously constant addresses. We accept that sometimes unforeseen (by the C users) problems can arise. And I'm not complaining, I just wanted to draw attention to the fact that non only gcc compiled programs run in Linux and that sometimes these changes hurt us.
Re: non C based environments can have problems Posted Jan 20, 2007 22:09 UTC (Sat) by scottt (subscriber, #5028) [Link] On my fedora system an implementation of the java virtual machine is labeled with the type "java_exec_t":$ ls -Z /usr/bin/gij -rwxr-xr-x root root system_u:object_r:java_exec_t /usr/bin/gij
Clearly sbcl want its own selinux policy module which grants it all the memory mapping priviledges it wants?
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.
Re: non C based environments can have problems Posted Jan 24, 2007 1:24 UTC (Wed) by ldo (subscriber, #40946) [Link] ...when errno was changed from an integer variable to a macro we had to handle that with some difficulty. I think having a global errno is such a dumb idea. Why can't system and library calls directly return an error code? ...but with the register-starved x86 architecture nobody seems to want to dedicate a register... I guess the extra registers in x86-64 must come as a relief, then. :)
Re: non C based environments can have problems Posted Jan 24, 2007 21:13 UTC (Wed) by dododge (subscriber, #2870) [Link] I think having a global errno is such a dumb idea. Why can't system and library calls directly return an error code? Tradition. Within the kernel, these sorts of functions typically do return
error codes directly. But the userspace API is so ingrained that
changing existing functions would break too much. As mentioned, even
just changing errno from being a global New APIs can of course use more sensible error reporting than errno if they want to. It could also be worse, though; for example the glibc obstack API by default aborts the program instead of returning an error, and while you can change that behavior you still have to rely on a global callback that at best uses something like setjmp/longjmp while running the risk of some library code changing the callback to something else. Yuck.
|
|||||||||||||