GrsecurityHowto

From Linix VServer
Revision as of 22:55, 10 November 2025 by 192.168.65.1 (talk) (Restored content from Wayback Machine)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Patches are at [grepmaster linux-vserver patch repository].

Procedure 1 (for the more paranoid)

  • grab vs1.Z-diff-for-grsecurity-1.9.X-2.4.Y.patch
  • inspect it to verify that I haven't added in nefarious things to the grsecurity patch
  • grab grsecurity-1.9.X-2.4.Y.patch from [www.grsecurity.net/download.php]
  • cat /path/to/vs1.Z-diff-for-grsecurity-1.9.X-2.4.Y.patch | patch -p0
  • apply resultant patch to your linux+vserver kernel tree

Procedure 2 (for the less paranoid)

  • grab grsecurity-1.9.X-2.4.Y-vs1.Z.patch
  • apply it to your linux+vserver kernel tree

As far as the grsecurity additional chroot restrictions go, I have the following turned off and all the rest turned on:

  • deny double-chroots
  • deny (f)chmod +s
  • capability restrictions within chroot

The first is necessary for gentoo emerge as well as running daemons within chroot (djbdns, or whatever). The second is necessary for upgrading packages with suid files in them (common task). The third does not seem necessary for Debian but breaks Gentoo emerge when turned on. There's currently an issue on using GR Security 1.9.x ACLs since once the ACL is applied the CAP_SYS_ADMIN is dropped and it can not be recovered for editing or disabling the ACL.

# gradm -E

# gradm -a

Password:

Could not open /proc/sys/kernel/grsecurity/acl

open: Permission denied

Kernel log shows this:

Mar 30 09:31:47 alus2 kernel: grsec: From 192.168.1.2: use of CAP_SYS_ADMIN denied for (gradm:1374) UID(0) EUID(0), parent (bash:706) UID(0) EUID(0)

(why it's denied? It never happens in grsec+gradm only)

The consecuence is that the first ACL can not be undone, it's permanent. Deep testing is recomended before using ACLs on production servers with GR Security + vserver patches.

[Thank you for explainig this issue - Maybe this is only an issue with grsecurity 1.9.x, because I use grsecurity 2.0/vserver 1.3.9 and after enabling the ACLs with "gradm -E" I can still get the admin role with "gradm -a admin" and then reload new ACLs with "gradm -R" - tested in context 0.]

send requests / compliments / flames to

jeffrey+vserver AT firehead DOT org