Grsecurity+Pax (Compiling Custom Kernels)

Discussion in 'all things UNIX' started by Linux38911, Mar 8, 2015.

  1. Linux38911

    Linux38911 Registered Member

    Joined:
    Feb 17, 2015
    Posts:
    9
    Location:
    Netherlands
    First of all I would like to explain myself about the interest in Grsecurity/Pax patched kernels.
    I am not a security specialist/admin by any means, also I'm not running any servers.
    Its just for personal, home use. Just to see how far I can 'secure' a typical linux box.

    I am very interested in some of the features that Grsecurity/Pax patch brings to a kernel.
    In general just a more restricted environment.

    I know how to compile and configure a custom kernel.
    I tried to compile a grsec kernel with success only to find out that a graphical user environment is somewhat problematic to get running when Grsecurity/Pax is in effect. I have read that mprotect() is one of the things keeping X from running and using drivers like Nvidia or ATI.
    As I understand it, it has to to do the way (raw) memory is accessed and that a really fully secure grsecurity kernel wouldn't allow proprietary video-drivers to run (this is not a bug, it really is a security issue.)

    However, being curious and all, would a custom kernel with Grsecurity/Pax be possible to use as a user in a graphical environment with proprietary video drivers ?
    Or is this really meant for Servers with no GUI.

    Is a custom kernel with Grsecurity/Pax just overkill or is it worth it to try to get it running ?
    I would love to hear your thoughts about this, even if this means I should not be bothered to try anything with Grsecurity. I greatly appreciate any thoughts and respect your views about it, also if it means "stay away from grsec kernels when you're just an average linux user!".

    Thanks in advance and cheers!
     
  2. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    You can work around the issue by using paxctl to disable mprotect() restrictions on specific programs, but personally I would just disable it globally. It's in the GrSec menu, under PaX options I believe. Also remember to disable RBAC if you don't plan on using it.

    Note that mprotect() restrictions are not the only thing that can interfere with software though. In particular, VirtualBox will never ever work under GrSec kernels.
     
  3. Linux38911

    Linux38911 Registered Member

    Joined:
    Feb 17, 2015
    Posts:
    9
    Location:
    Netherlands
    Indeed ! I must admit that I have to read more about disabling features that enables me as a user to run Grsec/PaX in a graphical environment.
    The point is that I am having difficulties to determine "how much" of Grsec I should disable to be able to use it or before it gets to the point "better off with a standard kernel".
    Thank you very much Gullible Jones for your input, much appreciated!
     
  4. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    Not sure. I believe mprotect() restrictions are a significant chunk of GrSec userspace memory protections. But a GrSec kernel should still be better off than a vanilla kernel, even without them; especially with respect to kernel vulnerabilities.
     
  5. Malwar

    Malwar Registered Member

    Joined:
    May 5, 2013
    Posts:
    271
    Location:
    USA
  6. Linux38911

    Linux38911 Registered Member

    Joined:
    Feb 17, 2015
    Posts:
    9
    Location:
    Netherlands
    Indeed, thanks Gullible Jones and Malwar.
    And I've already found insanitybit website some time ago, very good explanation about various stuff.

    Ehm, well I am currently running 3.18.9-grsec, so I've managed to get it to run, but with Nouveau drivers.
    The Nvidia drivers do work but only at the lowest resolution ! So, with nvidia drivers I'm stuck at 640*480 and can't change the settings to higher res.
    But with the Nouveau drivers i am able to get to full resolution and it works.

    I'm not sure how to do paxctl -m on my nvidia-drivers or that I must change other settings to enable them. Have to do some digging around.
     
  7. AutoCascade

    AutoCascade Registered Member

    Joined:
    Feb 16, 2014
    Posts:
    626
    Location:
    United States
    Someone should make implementing GRsecPax into an easy to add on security add on imo.

    This would make a huge step forward in Linux security which without it is not as secure that users believe it is.
     
  8. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
  9. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    @AutoCascade, a distribution would have to do it. GrSec will never be accepted in mainline. Currently Arch and Alpine ship GrSec kernels, though not as defaults; and there's a GrSec kernel repo for OpenSUSE, I believe. Other than that, nada.

    @Yuki2718 Tomoyo is harder to use than it looks, unfortunately. I would stick with AppArmor for pathname based access control. Another alternative might be SMACK, for label-based access control (but simpler than SELinux): https://www.kernel.org/doc/Documentation/security/Smack.txt

    SELinux might be worth looking into as well, actually. Only Fedora uses it for sandboxing (and not by default), but it also allows control of filesystem access. Keep in mind though that the X server is always going to be a weak point. Programs with access to X can all communicate with each other, past whatever MAC system.

    (Also GrSec has its own RBAC system, which can do some insane stuff; e.g. splitting root into several roles with different privileges. I should probably check that out some time...)
     
  10. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Thanks for quick and detailed response!:)
    Well, I haven't used Tomoyo so I'll at least try it. One reason I have interest on it is I find many resources about it in my mother tongue.
    I didn't know SMACK, I'll look into it tho I have a kind of "allergy" against label based control (not seriously, I like challenge :D)
    Thanks for your advice about X another thing I didn't aware of, and I was looking about RBAC part of GRSec and still not sure if it won't conflicts with SELinux's RBAC but at least Tomoyo don't have RBAC so I guess (rather, hope) no conflicts.
     
  11. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    @Yuki2718 one of the issues with Tomoyo is that (AFAICT) it doesn't follow symlinks by default. This causes problems on e.g. Debian, where /usr/bin/iceweasel may be linked to /usr/bin/firefox and in turn to /usr/bin/x-www-browser, etc. Invoke an app through a symlink Tomoyo is not configured to handle, and it will run unsandboxed!

    Re label based access control, I've never used it myself. Even SMACK looks rather complicated.
     
  12. AutoCascade

    AutoCascade Registered Member

    Joined:
    Feb 16, 2014
    Posts:
    626
    Location:
    United States
    Gullible from everything I've read Alpine comes as default with Grsec and Pax. It appears to be the only distro with that distinction well other than ChromeOS which has no available image. Chrome or Chromium does not seem to be an option for this.

    Alpine-related[edit]
    Alpine Linux began as a fork of the LEAF Project which was not a rolling release. In addition to point releases, users may update the system as individual packages become available.

    • Alpine Linux is a lightweight binary distribution with packaging tools similar to those of Arch. However, it has different policies for how its packages are compiled. Most notably the use of a smaller C library than glibc and the use of kernel features PaX and grsecurity by default.
     
  13. Malwar

    Malwar Registered Member

    Joined:
    May 5, 2013
    Posts:
    271
    Location:
    USA
    Your very welcome anytime. Yes it is a very good site, the owner is our member HungryMan here.:):thumb::cool:
     
  14. x942

    x942 Guest


    I have both Apparmor and RBAC enabled under my GRSec kernel. Running ontop of Debain here. GRSecurity and RBAC are meant to compliment existing security solutions. You can totally run and LSM with RBAC and GRSec. I quote from the GRSec page:

    Source.

    With this said I have never used Tomoyo. I only use apparmor and SeLinux on occasion. RBAC is amazing. It took a lot of reading and practice, but once it is up and running it is an awesome tool. I can't go back.
     
  15. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    First of all, I had quite fundamental misunderstanding maybe all you know. Tomoyo have 2 versions and 1.x is not a LSM but kernel patch (like GRSec?) while 2.x is LSM. So theoretically one can even apply GRSec + Tomoyo + LSM tho I will never do.
    I also find the discussion about them, but they have counter argument on it. Unfortunately that is beyond my expertise. As they don't provide English page here's Google translation of that (including other possible weakness and counter arguments) but thanks to fundamental syntax difference btwn Japanese and English, translation quality is terrible.
    https://translate.google.com/transl...sourceforge.jp/wiki/?path-vs-label&edit-text=

    Currently I'm still lerning about those but the more learn about them, the more I feel I may go to AppArmor as you advised. My purpose is to ultra-securely browse web and possibly document viewing/editing and email too. Basically am thinking to build minimal setup so Arch is best I think. For this purpose, maybe securing browser (and possibly office program and email client) will be good enough while Tomoyo protects all system.
    BTW, your past post is quite helpful!;)
     
  16. tlu

    tlu Guest

    Yuki, Arch is a good choice, IMHO. I've been running it for about 1 year, and I'm happy with it. However, note that support for AppArmor, SELinux and Tomoyo was removed in April 2014. There are packages in the AUR which provide those functionalities but they are more or less half-baked, IMHO.
    One nice alternative would be Firejail (also available from the AUR), though. It's discussed here, two postings of mine might be helpful. So far, I'm using Firejail with Chrome, Firefox, Thunderbird, QuiteRSS and LibreOffice. More details here where you will also find links to the manpages.
     
  17. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Thank you very much tlu for your comment!
    As I'm not much familiar with Linux, I didn't know Arch until recently and I felt it is the distro I've been seeking. I didn't like that I had to uninstall so many components on Ubuntu, and as they started to sell privacy to Amazon I realized I'll never use Ubuntu again at least for main OS.

    Fortunately, I know a guide to enable Tomoyo 2.x on kernel 3.14+.

    I've been watching Firejail thread too, and it seems promissing. I saw if you already applied AA, only benefit FJ add to it is blacklist, right?
    How about opposite case, if I applied FJ then there's no merit by AA?

    I still think I will try Tomoyo 2.x first. Tomoyo 1.x gives bit better security but it seems there's more obstacle for me to use 1.x compared to 2.x. If I understand it is too difficult for me, I'll switch to AA which I had a little experience.

    In any case, I'll definately try FJ as long as there's additional merit.
     
Loading...