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.malo...@yahoo.ca> 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 <jaro...@dyne.org> 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@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > > > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng