Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 14357 Details for
Bug 24248
Startup script for grsecurity
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
grsecurity startup script configuration file
grsconfity (text/plain), 16.63 KB, created by
mlmoser
on 2003-07-10 14:52:11 UTC
(
hide
)
Description:
grsecurity startup script configuration file
Filename:
MIME Type:
Creator:
mlmoser
Created:
2003-07-10 14:52:11 UTC
Size:
16.63 KB
patch
obsolete
># grsecurity configuration file ># part of the grsecurity init.d script writen for Gentoo by Bluefox Icy ># DO NOT SIMPLIFY THIS FILE! IT TOOK ME OVER FOUR HOURS TO WRITE THIS AND I ># WILL BE PISSED OFF AT YOU AND MIGHT FIND YOU AND KICK YOUR ASS!!! BZIP2 IT ># FOR DISTRIBUTION GOD!!!!! > ># This is distributed under GPL v2.0. All clauses apply, especially those of ># NO WARRENTY > ># This file contains options GRSEC_{SYSCTL} which are read by the grsecurity ># init.d script and used to set the sysctl's. ># ># These each have a description attatched to them. Read it. Or just read in ># the configure help for the kernel. > ># This indicates to the script where the grsecurity sysctl interface is. ># Change if you were smart and hacked grsecurity to move this out of the way of ># stupid virii/trojans that attack it. A good place would be inside a PID, ># assuming you can block one of the PID's from all but root's view. ># ># Note: The most secure option is to hide the grsecurity sysctl interface in a ># randomly generated subdir under /proc that is only visible if a file inside ># of it is opened for writing, and then add a custom kernel system call that ># only a custom binary knows about, which retrieves this directory and allows ># you to write into it (echo_grsecurity grsec_sysctl_foo grsec_sysctl_value) >GRSECURITY_SYSCTL_DIR="/proc/sys/kernel/grsecurity" > ># Set this to 1 if you wish for errors in loading the grsecurity startup script ># to trigger a `telinit 1`, turning the system into a brick that only root can ># manipulate. This is for i.e. servers that must NOT be broken into. >GRSECURITY_CRITICAL=0 > ># Set this to 1 if you do NOT want anyone to know where GRSYSDIR is! On any ># error other than the final lock, GRSYSDIR is spewed onscreen. Obviously, ># root can just come in here and check, so it is recommended this option be ># enabled, especially if you use a hacked version of grsecurity with a ># personalized sysctl directory (extra security against crackers) >GRSECURITY_HIDESYS=1 > ># -The final locker- ># Of all the sysctls out there, there's one that you should NOT touch until you ># have finished editing the rest of grsecurity: ># grsec_lock ># This one is controlled not by GRSEC_GRSEC_LOCK, but by GRSEC_AUTO_GRSEC_LOCK ># instead. This is because the name is self-descriptive: Automatically lock ># grsec. THIS MUST BE ON!!!! If it is not on, you're an idiot. If it is not ># on, then just about any process can modify these by hacking the sysctl's. ># Enabling this will lock out grsecurity completely, which means once it's on, ># you're stuck with the current settings until you reboot. This SHOULD happen ># in your start-up scripts. ># ># Also note that because we are using sysctl, this file and your init.d scripts ># should be read only (place in an ACL system). Also, root should not have ># access to raw I/O or to adding modules. These are just suggestions, because ># sysctl in grsecurity could possibly reduce the effectiveness of grsec by ># adding yet another security hole: A way to alter the grsecurity settings. ># If you are really concerned, compile in everything you want, and turn off ># sysctl. At any rate, these security measures are only to protect grsecurity, ># so unless you secure down your init scripts and your kernel, you are only ># risking being reverted to a kernel without grsecurity, at worst. >GRSECURITY_AUTO_GRSEC_LOCK=1 ># This of course negates the above if you have an error >GRSECURITY_NO_LOCK_ON_ERROR=1 > ># ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Hide kernel processes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ># ³ CONFIG_GRKERNSEC_ACL_HIDEKERN: ³ ># ³ ³ ># ³ If you say Y here, when the ACL system is enabled via gradm -E, ³ ># ³ an additional ACL will be passed to the kernel that hides all kernel ³ ># ³ processes. These processes will only be viewable by the authenticated ³ ># ³ admin, or processes that have viewing access set. ³ ># ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ > ># acl ># I assume that is it above. Seems TO NOT WORK, DISABLED IN init.d SCRIPT! ># Also: ># [*] Hide kernel processes ># (3) Maximum tries before password lockout ># (30) Time to wait after max password tries, in seconds ># GRSEC_ACL=1 > > > ># ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Linking restrictions ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ># ³ CONFIG_GRKERNSEC_LINK: ³ ># ³ ³ ># ³ If you say Y here, /tmp race exploits will be prevented, since users ³ ># ³ will no longer be able to follow symlinks owned by other users in ³ ># ³ world-writeable +t directories (i.e. /tmp), unless the owner of the ³ ># ³ symlink is the owner of the directory. users will also not be ³ ># ³ able to hardlink to files they do not own. If the sysctl option is ³ ># ³ enabled, a sysctl option with name "linking_restrictions" is created. ³ ># ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ > ># linking_restrictions ># Explained above >GRSEC_LINKING_RESTRICTIONS=1 > > > ># ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FIFO restrictions ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ># ³ CONFIG_GRKERNSEC_FIFO: ³ ># ³ ³ ># ³ If you say Y here, users will not be able to write to FIFOs they don't ³ ># ³ own in world-writeable +t directories (i.e. /tmp), unless the owner of ³ ># ³ the FIFO is the same owner of the directory it's held in. If the sysctl ³ ># ³ option is enabled, a sysctl option with name "fifo_restrictions" is ³ ># ³ created. ³ ># ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ > ># fifo_restrictions ># Explained above >GRSEC_FIFO_RESTRICTIONS=1 > > > ># ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Chroot jail restrictions ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ># ³ CONFIG_GRKERNSEC_CHROOT: ³ ># ³ ³ ># ³ If you say Y here, you will be able to choose several options that will ³ ># ³ make breaking out of a chrooted jail much more difficult. If you ³ ># ³ encounter no software incompatibilities with the following options, it ³ ># ³ is recommended that you enable each one. ³ ># ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ > ># There are a lot of well-known, semi-known, and possible methods of breaking ># chroot jails here. Watch out. > ># chroot_deny_mount ># Deny mounts from within chroot jails >GRSEC_CHROOT_DENY_MOUNT=1 > ># chroot_deny_chroot ># Deny doing a chroot from within chroot >GRSEC_CHROOT_DENY_CHROOT=1 > ># chroot_deny_pivot ># Deny doing a pivot_root() from inside a chroot (including the pivot_root ># program, which just calls the pivot_root() function) >GRSEC_CHROOT_DENY_PIVOT=1 > ># chroot_enforce_chdir ># Force programs chroot()'d to first chdir to / (the new chroot root). Without ># this, calling chroot() may leave the processes in a . which is above the new ># /, which lets them wreak havoc. >GRSEC_CHROOT_ENFORCE_CHDIR=1 > ># chroot_deny_chmod ># Prevent chrooted programs from setting suid/sgid bits on files >GRSEC_CHROOT_DENY_CHMOD=1 > ># chroot_deny_fchdir ># Prevent chrooted programs from chdir'ing to a file descriptor that is outside ># the chroot >GRSEC_CHROOT_DENY_FCHDIR=1 > ># chroot_deny_mknod ># Deny chrooted programs the opportunity to mknod a device and subsiquently use ># that device to get raw access to your disks, network, and other media >GRSEC_CHROOT_DENY_MKNOD=1 > ># chroot_deny_shmat ># Prevent processes from attatching to shared memory segments created outside ># the chroot jail they are in >GRSEC_CHROOT_DENY_SHMAT=1 > ># chroot_deny_unix ># Prevent processes inside a chroot from connecting to abstract (meaning not ># belonging to a filesystem) Unix domain sockets that were bound outside of a ># chroot >GRSEC_CHROOT_DENY_UNIX=1 > ># chroot_findtask ># Prevents any process in a chroot jail from seeing or communicating with any ># process outside the jail >GRSEC_CHROOT_FINDTASK=1 > ># chroot_restrict_nice ># Prevent processes inside a chroot jail from raising the priority of processes ># inside the chroot, or altering the priority of processes outside the chroot >GRSEC_CHROOT_RESTRICT_NICE=1 > ># chroot_deny_sysctl ># Cannot use sysctl(2) or /proc interfaces to hack sysctls from a chroot jail >CHROOT_DENY_SYSCTL=1 > ># chroot_caps ># Prevents all root processes within a chroot jail from inserting modules, ># doing raw i/o, performing system and net admin tasks, rebooting the system, ># modifying immutable files, modifying IPC owned by another, and changing the ># system time. This MAY break some apps. >GRSEC_CHROOT_CAPS=1 > > > >################################################################################ ># Kernel Auditing # ># # ># These options control logging. BE CAREFUL! May produce EXCESSIZE logs and # ># use A LOT of disk!!!! (sounds like this script...) # ># Don't turn these on if you don't read your logs -.- # >################################################################################ > ># audit_group, audit_gid ># Causes the exec, chdir, (un)mount, and ipc logging features to only watch a ># certain group. audit_gid is the gid to use (default 1007) >GRSEC_AUDIT_GROUP=1 >GRSEC_AUDIT_GID=1007 > ># exec_logging ># WARNING: CAUSES EXCESSIVE LOGS AND FILLS UP DISK FAST!!!! ># NOTICE: Affected by audit_group, audit_gid ># Logs all execution. ALL execution. Everything ran. >GRSEC_EXEC_LOGGING=0 > ># chroot_execlog ># WARNING: MAY PRODUCE EXCESSIVE LOGS!!!! ># NOTICE: Affected by audit_group, audit_gid [I *think*] ># Same as exec_logging, but only inside chroot jails. >GRSEC_CHROOT_EXECLOG=0 > ># audit_chdir ># NOTICE: Affected by audit_group, audit_gid ># Logs chdir() calls >GRSEC_AUDIT_CHDIR=0 > ># audit_mount ># NOTICE: Affected by audit_group, audit_gid ># Logs all mounts/umounts >GRSEC_AUDIT_MOUNT=0 > ># audit_ipc ># NOTICE: Affected by audit_group, audit_gid ># Logs creation and removal of message ques, semaphores, and shared memory >GRSEC_AUDIT_IPC=0 > ># signal_logging ># Logs all important signals, like SIGSEGV, which could indicate an exploit ># (cracker attack) attempt. Pretty docile unless your apps crash a lot. ># Enable the address space layout randomization (enabled in default binaries I ># hope, as it's safe) to cause such attacks to cause this more often (i.e. ># because the attackers no longer know where the part of the program they want ># to hit is, they put code in the wrong place, and crash it, thus failing to ># break into your system) >GRSEC_SIGNAL_LOGGING=1 > ># forkfail_logging ># Logs failed attempts to fork(), which may indicate a fork bomb or an attempt ># by a user to get more resources than allowed >GRSEC_FORKFAIL_LOGGING=0 > ># timechange_logging ># Log changes to the system time, which should happen.. just about never >GRSEC_TIMECHANGE_LOGGING=0 > > > >################################################################################ ># Executable Protection # ># # ># Stuff to control executables, i.e. make sure that the users can't eat up # ># more resources than they're allowed, read dmesg, or execute world-writable # ># files (i.e. files that may be infected with viruses) # >################################################################################ > ># execve_limiting ># Checks for users overstepping their resource limits on processes at ># execution, rather than waiting for running processes to fork() >GRSEC_EXECVE_LIMITING=1 > ># dmesg ># Blocks non-root users from viewing the last 4k of the kernel's log buffer >GRSEC_DMESG=1 > ># rand_pids ># Generates pseudo-random process ID's, to make it EXTREMELY difficult to guess ># the PID's of daemons. Especially annoying if you're a shell user not allowed ># to view processes you don't own, and you're trying to send data to a daemon ># to exploit another root-access bug ># TURN THIS ON! Also, make sure the /proc protections are on (just do a ps -A ># as a normal user and see if it refuses to show some of the stuff that a ps -A ># shows as root) to keep users from looking up the PID's of processes they ># don't own >GRSEC_RAND_PIDS=1 > ># tpe, tpe_gid ># Lets you mark certain users as "untrusted" and thus restrict their execution ># rights. The restriction is as follows: Users in group tpe_gid are refused ># execution of any programs not in root-owned directories writable only by root ># (i.e. can't bring in their own program, can't inject virii into anything they ># can run) >GRSEC_TPE=1 >GRSEC_TPE_GID=1005 > ># tpe_restrict_all ># Restricts all users not in group tpe_gid to executing files either: ># A) In directories they own that are not group- or world-writable (i.e. the ># default state of the HOME directory) ># B) Executable by the untrusted users (root-owned dir's and root writable) ># Annoying? Yes, at times. All properly installed programs are fine. All ># programs in a *proper* home directory are fine. As for compiling.. well, if ># you don't compile in ~/, then you need to: ># $ chown -R USER foo_src_tree ># $ chmod -R a-w,u+w foo_src_tree ># before any ./configure or make will work. Note that you have to first own it ># before you can chown/chmod it, so root has to do the first line at least >GRSEC_TPE_RESTRICT_ALL=1 > > > >################################################################################ ># Network Protections # ># # ># These things hit network attacks right in the ass. Random ISN's, random # ># IP ID's, random source ports, and restricted socket access keep crackers on # ># the outside from guessing who you are (i.e. OS fingerprints) and tracking # ># your connections, as well as crackers already inside from running servers and# ># letting the rest of hell in. # >################################################################################ > ># rand_isns ># Makes TCP Initial Sequence Numbers truly random >GRSEC_RAND_ISNS=1 > ># rand_ip_ids ># Randomizes the IP ID's on fragmented packets to hinder OS fingerprints and ># prevent the system from being used as a bounce for untraceable portscans ># Has a probability of near 0 of creating duplicate ID's. Actually, if you ># ever log a duplicate ID, send it in ;-) It'd be interesting to see, though ># not likely to happen in your lifetime unless you're using the full bandwidth ># of a switched gigabit or 10gig network 24/7 >GRSEC_RAND_IP_IDS=1 > ># rand_tcp_src_ports ># When a port is generated on the fly (i.e. connect to a webserver on port 80 ># from some other port because we have our own web server running on our port ># 80), the source port is generated at random instead of with an incrimenting ># algorithm >GRSEC_RAND_TCP_SRC_PORTS=1 > ># rand_rpc ># If you say 1 here, the method of determining XIDs for RPC requests will be ># randomized >GRSEC_RAND_RPC=1 > ># altered_pings ># Using this will cause Linux to reply to echo requests with a reply having the ># same ID as the request. This confues OS detection programs, so turn it on >GRSEC_ALTERED_PINGS=1 > > > ># ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Socket restrictions ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ># ³ CONFIG_GRKERNSEC_SOCKET: ³ ># ³ ³ ># ³ If you say Y here, you will be able to choose from several options. ³ ># ³ If you assign a GID on your system and add it to the supplementary ³ ># ³ groups of users you want to restrict socket access to, this patch ³ ># ³ will perform up to three things, based on the option(s) you choose. ³ ># ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ > ># socket_all, socket_all_gid ># Blocks users in the given group from using sockets, i.e. to connect to other ># hosts (using web browsers, xchat, gftp, etc) or to run servers (ircd, apache, ># wu-ftpd, etc) >GRSEC_SOCKET_ALL=1 >GRSEC_SOCKET_ALL_GID=1004 > ># socket_client, socket_client_gid ># Blocks users in the given gid from using sockets to connect to other hosts, ># but allows them to run servers >GRSEC_SOCKET_CLIENT=1 >GRSEC_SOCKET_CLIENT_GID=1003 > ># socket_server, socket_server_gid ># Blocks users in the given gid from using sockets to run servers >GRSEC_SOCKET_SERVER=1 >GRSEC_SOCKET_SERVER_GID=1002 > ># end of file
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 24248
:
14355
|
14356
| 14357