[lug] SELinux

mad.scientist.at.large at tutanota.com mad.scientist.at.large at tutanota.com
Mon Jan 29 13:38:20 MST 2018


sorry, haven't used the various flavors of java.  If it's compiled, then such flaws are a compiler problem or a problem with the java engine.  I assume the JVM bytecode is run on an interpreter, similar to the way pascal produces code for a hypothetical machine, though some pascal compiler do provide target code.

good info, i thank all.  definately worth the hassle if properly configured and one stays away from dodgey/poorly written compilers and interpreters.  I'm well aware that all code of any size/complexity will have bugs, plus bugs from compilers/interpreters.  heap and stack overflow exploits continue to be common, as well as other security holes.   trading proper data/instructions isolation in memory is a very poor practice and terrible way to get speed.  I know well firefox's myriad problems.



mad.scientist.at.large (a good madscientist)
--
God bless the rich, the greedy and the corrupt politicians they have put into office.   God bless them for helping me do the right thing by giving the rich my little pile of cash.  After all, the rich know what to do with money.


29. Jan 2018 13:20 by bgiles at coyotesong.com:


> ? Java isn't interpreted. It compiles to JVM bytecode but the JIT optimizer is now good enough that it can outperform C on long-running code.
> It's worth noting that Java's myriad security weaknesses (after the first few years when poor decisions were shaken out) reflect the fact that it's such a high value target that attackers will look at obscure corner cases. It's not proof that it's inherently less secure than other platforms (*cough* C libraries) and it has a lot of features that would make systems much more secure if people used them. You can certainly design more secure virtual machines but you'll lose functionality, at least at the moment.
> On Sun, Jan 28, 2018 at 10:04 PM,  <> mad.scientist.at.large at tutanota.com> > wrote:
>
>>           >> that's just one more reason not to write things in java.  if i were "enterprise" i'd probably be doing the writing in a real language, for most things i hate interpreted languages, they are slow, slow, slow if doing any real work.  But i do see you're point, considering how "HOT" java is.  I mean the whole point is security, using java is hardly helpful in that pursuit, but i know you have to give the customer what they want.
>>
>> Yes, i will learn it as it's another usefull layer for security in depth.  I also plan to run multiple, different firewalls (banking industry standard, for web access is 3 layers of fire wall from different vendors, last i heard anyway).
>>
>> mad.scientist.at.large (a good madscientist)
>> --
>> God bless the rich, the greedy and the corrupt politicians they have put into office.   God bless them for helping me do the right thing by giving the rich my little pile of cash.  After all, the rich know what to do with money.
>>
>>
>> 28. Jan 2018 21:16 by >> zlynx at acm.org>> :
>>
>>
>>> On 1/28/2018 4:11 PM, >>> mad.scientist.at.large at tutanota.com>>>  wrote:
>>>> the defaults in centos 6.9 (run by RH) enables many dangerous options by default, like executing code in the heap or memory shared with variables and program,
>>>
>>> You cannot run Java applications without those things. Just try being "enterprise" without Java.
>>> _______________________________________________
>>> Web Page:  >>> http://lug.boulder.co.us
>>> Mailing List: >>> http://lists.lug.boulder.co.us/mailman/listinfo/lug
>>> Join us on IRC: >>> irc.hackingsociety.org>>>  port=6667 channel=#hackingsociety
>>   
>> _______________________________________________
>> Web Page:  >> http://lug.boulder.co.us
>> Mailing List: >> http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: >> irc.hackingsociety.org>>  port=6667 channel=#hackingsociety
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20180129/89c427ce/attachment.html>


More information about the LUG mailing list