On 03/08/2015 08:25 AM, Neo Futur wrote: >> cool, thanks! I think it would be important that packages that have an issue >> running under grsec all do what they need to do on installation to make sure >> the correct configs are in place to actually work under grsec. This is often >> left out, making proper security expensive and difficult to track down. > lets be clear, you d have to check for each and every new version of > each and every binary you ship to add this "allowed to skack exec or > whatever other dirty memory trick" flag whenever the upstream added a > bug or a backdoor. > > quite a bunch of work, imo this have to be the responsibility of the > sysadmin to see the problem ( easy in the grsec log whenever something > goes wrong ) and choose to allow/trust this binary, and / or report a > bug to devuan and/or upstream. It's not much work... I just stick those setfattr commands in a script and run it each time I run system updates (but I wish there was some "post update hooks" thing I could put it, so also unattended-upgrades or similar will also set the flags). And on a server, it's pretty much just java and maybe python that have issues (and the grub one is somehow debian only). Mostly everything else I had to set flags on was on my desktops. > also automatically adding this flag everywhere completely defeats the > purpose of those security patches, you just say "wow this program have > a backdoor, cool its allowed, dont even log that" to your grsec > kernel, why not ship a grsec kernel with no security options enabled > then ? or just use vanilla It certainly opens some holes, but they're much smaller issues than having a vanilla kernel. For example try paxtest to see how open a vanilla kernel is, and then try grsec, and then try grsec with the flags set on the paxtest binary and shared objects, and it's barely worse
And people in the grsec irc channel assure me that even though setting all the flags on a binary opens up buffer overflow, etc. exploits to the userland application, it still protects the kernel fully (no flags to set there) and so the damage that application can do is limited to just userspace; with apparmor or something confining the application, then the damage is nearly nothing... eg. firefox can add addons, bookmarks, connect to web pages, download files (my firefox profile doesn't let it do anything else, just save files in one dir), etc. and then if it's corrupted I can just remove my config (~/.mozilla/profiles/...), and it can't affect the rest of the system. And the biggest fear when using LSM or other mandatory access control (MAC) is kernel exploits... if someone can execute code running in the kernel, they can easily bypass MAC. So it's a huge improvement even with the flags set. > > >> _______________________________________________ >> 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
