[lug] SELinux

Mon Jan 29 14:32:54 MST 2018

It's the same as debugging optimized C code. When you single-step through
the code the lines of code might not be executed sequentially but they're
never reordered in a way that breaks the logic. Remember that keyhole
optimizers work on a very limited set of patterns so they can be proven to
be correct.

On Mon, Jan 29, 2018 at 2:01 PM, <mad.scientist.at.large at tutanota.com>
wrote:

> so how can anyone debug or audit code if the JIT compiler keeps optimizing
> it repeatedly, cosnstantly changing the machine language code.  you'd have
> to debug the jit compiler and your' code at the same time. again i think
> this is terrible design for reliability and security as there is no way to
> audit the actual machine code.  this constant optimizing sounds like an
> excellent way to introduce unpredictable (or nearly so) bugs and frustrate
> any attempt to solve hard bugs or even guess where the bugs are in the code.
>
> I do realize java has had a lot more development time spent on it than
> pascal.
>
> 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:54 by bgiles at coyotesong.com:
>
>
> It's really unfair to compare the JVM to the pascal p-machine. There's a
> superficial similarity but it's had 20 years of optimizations by smart
> people with strong motivations. Hence things like the JIT (just-in-time)
> optimizer. The JVM is machine-independent but the JIT is a
> platform-specific keyhole optimizer that can replace blocks of bytecode
> with optimized native code. It gets more aggressive about unrolling loops,
> inlining method, etc., as the block of code is repeatedly called. A
> long-running server may be mostly optimized native code.
>
> On Mon, Jan 29, 2018 at 1:38 PM, <mad.scientist.at.large at tutanota.com>
> wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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/7135224e/attachment.html>