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@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>