yes with grsec you can allow stack exec if you dont think its a security flaw

I just said "as a default" :

>* shipping the kernel with warnings that, as a default, java wont work
>with a secure kernel, and possibly any other graphical applications
>doing dirty stuff with memory ( buffer overflow, relocations and much
>more )


On Sat, Mar 7, 2015 at 4:48 PM, Peter Maloney <peter.maloney@???> wrote:
> Just to clarify... Java will run with a grsecurity hardened kernel, with pax
> enabled. It just needs mprotect disabled for the specific programs that need
> it disabled. (and also many other things need this... python, kdeinit4,
> skype, kscreenlocker_greet, thunderbird, firefox, plugin-container, gdb,
> utox, grub-probe, etc. also firefox needs JIT disabled for optimal
> stability). For this you need some kernel features enabled; I recommend the
> one using xattrs because then the binaries don't need modifications (or
> backups, and modified binaries won't run properly in a non-grsec kernel, but
> they run fine with xattrs).
>
> Set the extended file system attribute with:
>
> setfattr -n user.pax.flags -v m /usr/lib*/jvm/java-*-openjdk-*/jre/bin/java
>
> (example path, may not be right for Debian openjdk)
>
> I have been running grsecurity kernels on my desktop at home and the office
> for about a year now, with Java and everything in use.
>
> Also, you can set pax to "soft mode" to temporarily disable those
> protections.
>
> And the kernel buffer displays errors when such things are needed, so it is
> easy enough to identify why a program doesn't work, to enable those flags:
>
> [ 477.346273] PAX: From 192.168.179.200: execution attempt in: <stack>,
> 3cc7c968000-3cc7c989000 3fffffde000
> [ 477.346451] PAX: terminating task:
> /usr/bin/grub-script-check(grub-script-che):7163, uid/euid: 0/0, PC:
> 000003cc7c987cf0, SP: 000003cc7c986698
> [ 477.346631] PAX: bytes at PC: 41 bb 30 27 40 00 49 ba e0 7c 98 7c cc 03
> 00 00 49 ff e3 90
> [ 477.346784] PAX: bytes at SP-8: 00000000044d68d0 0000000000404011
> 0000000000000001 0000000000000000 00000000044d6850 00000000044d68d0
> 00000000044d68d1 00000000044d8911 00000000044d8910 0000000000405ca6
> 0000000000000002
>
>
>
> On 03/07/2015 12:31 PM, Martijn Dekkers wrote:
>
> I am not sure I follow - is the plan for Devuan to be default
> hardened/grsec, or is it supposed to be an optional choice somehow? As was
> already pointed out, java won't run. Lots and lots of server workloads run
> Java....
>
> On 7 March 2015 at 12:42, Jaromil <jaromil@???> wrote:
>>
>>
>> dear Neo Futur and other members of the Devuan hardening team:
>>
>> please consider the Alpha release series a minimal base you can use to
>> start working on the kernel patches, building them and testing them.
>> In fact, this release series is mostly intended to receive feedback from
>> developers and adjust to their needs.
>>
>> Please also let me know what is the format you prefer working on. Right
>> now I can release virtualbox images and vagrant boxes using the SDK but
>> I can also add support for Docker, Qemu, AWS, Google engine,
>> DigitalOcean, OpenStack, Parallels etc.
>>
>> In a close future Devuan's signed releases will be available in all
>> these formats, hoping they come handy to the sysadmins among our
>> audience. I'm just trying to figure out what to prioritize now in order
>> to facilitate your good plans.
>>
>> ciao
>>
>>
>>
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>