* Huagang Xie (xieat_private) wrote: > ChangeLog, > - klids convert to use workqueue and make it working. > - fixed a bug when access a unreadable file. > - fixed Makefile for the include directory Thanks, applied (to 2.5.46). This has a few compile issues which I've cleaned up (__FUNCTION__ pasting issues, and the DECLARE_COMPLETION(done) bit in lids_klids_init looks bogus. It needs to be first since it declares an auto variable, so it won't compile. And since it is never used I removed it). Also, converted to Kconfig. Attached is the diff for changes. Note: The following config items were only in Config.help and have been dropped completely. CONFIG_LIDS_INIT_CHILDREN_LOCK CONFIG_LIDS_FLOOD_EVENT_THRESHOLD CONFIG_LIDS_FLOOD_EVENT_INTERVAL CONFIG_LIDS_REMOTE_SWITCH And the following are commented out in Config.in, and consequently dropped. These are still referenced in the code however, please clean accordingly: CONFIG_LIDS_PORT_SCAN_DETECTOR CONFIG_LIDS_HIDE_KLIDS -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net # This patch includes the following deltas: # ChangeSet 1.535 -> 1.537 # security/Kconfig 1.1 -> 1.2 # security/lids/Config.help 1.1 -> (deleted) # security/lids/Config.in 1.3 -> (deleted) # security/lids/klids.c 1.5 -> 1.6 # security/lids/include/linux/lidsext.h 1.2 -> 1.3 # security/lids/lids_exec.c 1.9 -> 1.10 # (new) -> 1.1 security/lids/Kconfig # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/11/06 chrisat_private 1.536 # Kconfig updates for security/Kconfig and security/lids/Kconfig # -------------------------------------------- # 02/11/06 chrisat_private 1.537 # LIDS: # - fix __FUNCTION__ pasting errors # - remove DECLARE_COMPLETION(done) from klids.c as it's wrong and doesn't # appear to be used. # -------------------------------------------- # diff -Nru a/security/Kconfig b/security/Kconfig --- a/security/Kconfig Wed Nov 6 17:19:42 2002 +++ b/security/Kconfig Wed Nov 6 17:19:42 2002 @@ -5,11 +5,134 @@ menu "Security options" config SECURITY_CAPABILITIES - bool - default y + tristate "Capabilities Support" help This enables the "default" Linux capabilities functionality. If you are unsure how to answer this question, answer Y. -endmenu +source security/selinux/Kconfig + +config SECURITY_OWLSM + tristate "LSM port of Openwall (EXPERIMENTAL)" + depends EXPERIMENTAL + help + This enables the LSM port of the Openwall kernel patch. + This is NOT official Openwall. For more information on the + Openwall kernel patch go to <http://www.openwall.com/> + + The Openwall kernel patch consists of 8 parts: + CONFIG_SECURE_STACK, CONFIG_SECURE_STACK_SMART, + CONFIG_SECURE_LINK, CONFIG_SECURE_FIFO, CONFIG_SECURE_PROC, + CONFIG_SECURE_FD_0_1_2, CONFIG_SECURE_RLIMIT_NPROC, and + CONFIG_SECURE_SHM. + + Owlsm currently implements the CONFIG_SECURE_LINK, + CONFIG_SECURE_FD_0_1_2, and CONFIG_SECURE_RLIMIT_NPROC. + + Owlsm does not currently implement the CONFIG_SECURE_FIFO + and CONFIG_SECURE_PROC. + + Owlsm probably will not implement the CONFIG_SECURE_STACK, + CONFIG_SECURE_STACK_SMART, CONFIG_SECURE_SHM portions of the + Openwall kernel patch. The stack patches do not naturally lend + themselves to implementation via LSM. CONFIG_SECURE_SHM is no + longer needed in the >= 2.4 kernel. In the 2.2 kernel, memory + was allocated when the shared memory segment was created. The + 2.4 kernel delays allocating memory until the segment is + used. Thus, the resource exhaustion that this patch was meant to + protect against is not an issue. shmid exhaustion is possible, + but impact of this is low and the invasiveness of the kernel + changes required to port this piece to LSM is so high as to + not justify doing it. In order to port the CONFIG_SECURE_SHM + to LSM, a new hook would have to be added to shm_close and the + symbols shm_destroy(), ipc_lock(), ipc_unlock(), and shm_ids + would have to be exported. +config OWLSM_RLIMIT_NPROC + bool "Add RLIMITS_NPROC check to execve" + depends on SECURITY_OWLSM + help + This option is an LSM port of the Openwall + CONFIG_SECURE_RLIMIT_NPROC patch. It is derived from + Openwall but is not official Openwall. This option is only + valid if you have chosen to build the LSM port of Openwall + (CONFIG_SECURITY_OWLSM). + + Linux lets you set a limit on how many processes a user can + have, via a setrlimit(2) call with RLIMIT_NPROC. Unfortunately, + this limit is only looked at when a new process is created + on fork(2). If a process changes its UID, it might exceed the + limit for its new UID. This is not a security issue by itself, + as changing the UID is a privileged operation. However, there're + privileged programs that want to switch to a user's context, + including setting up some resource limits. The only fork(2) + required (if at all) is done before switching the UID, and + thus doesn't result in a check against RLIMIT_NPROC. Enable + this option to enforce RLIMIT_NPROC on execve(2) calls. + + If you are unsure how to answer this question, answer N. + + +config OWLSM_LINK + bool "Restricted links in /tmp" + depends on SECURITY_OWLSM + help + This option is an LSM port of the Openwall CONFIG_SECURE_LINK + patch. It is derived from Openwall but is not official + Openwall. This option is only valid if you have chosen to + build the LSM port of Openwall (CONFIG_SECURITY_OWLSM). + + There's a very common attack that involves a malicious user + creating a symbolic link in /tmp, with a carefully chosen + name, pointing at another user's file. When the victim then + writes to that file name, without the required precautions, + they inadvertently write to the wrong file. Enabling this + option reduces the impact of this class of holes (some get + fixed, many others allow for DoS attacks only, most of the + rest become harder to exploit) by preventing a process from + following a link which is in a +t directory, unless the link + owner is trusted (that is, it's the user we're running as or + the directory owner). To prevent from using a hard link in an + attack instead, this option does not allow users to create hard + links to files they don't own. This might break things. Say + Y if security is more important. + + +config OWLSM_FD + bool "Special handling of fd 0, 1, and 2" + depends on SECURITY_OWLSM + help + This option is an LSM port of the Openwall + CONFIG_SECURE_FD_0_1_2 patch. It is derived from Openwall + but is not official Openwall. This option is only valid + if you have chosen to build the LSM port of Openwall + (CONFIG_SECURITY_OWLSM). + + File descriptors 0, 1, and 2 have a special meaning for the C + library and lots of programs. Thus, they're often referenced + by number. Still, it is normally possible to execute a program + with one or more of these fd's closed, and any open(2) calls + it might do will happily provide these fd numbers. The program + (or the libraries it is linked with) will continue using the + fd's for their usual purposes, in reality accessing files + the program has just opened. If such a program is installed + SUID and/or SGID, then we might have a security problem. + Enable this option to ensure that fd's 0, 1, and 2 are always + open on execution of a SUID/SGID binary. + + +config SECURITY_DTE + tristate "Domain and Type Enforcement (EXPERIMENTAL)" + depends on EXPERIMENTAL + help + This enables Domain and Type Enforcement. It assigns labels to + files and processes. File labels are called types, and process + labels are called domains. DTE controls transitions and signal + access between domains, and access from domains to types. For + more information, please see <http://www.cs.wm.edu/~hallyn/dte> + + If you're unsure, answer N. + +source security/lids/Kconfig + +endmenu diff -Nru a/security/lids/Config.help b/security/lids/Config.help --- a/security/lids/Config.help Wed Nov 6 17:19:42 2002 +++ /dev/null Wed Dec 31 16:00:00 1969 @@ -1,248 +0,0 @@ -Intrusion Detection System support (EXPERIMENTAL) -CONFIG_LIDS - LIDS - Linux Intrusion Detection System can let you protect your linux - kernel. - - In order to use LIDS, you need to download the lidstools first from - http://www.lids.org/ - - Please read help provided with each option carefully. At the end of - each option we indicate what answer will increase security. - Be aware that security always has side effects, and some programs could - break. - - If you have any questions about LIDS, mail to the authors : - Huagang Xie ( xieat_private) - Philippe.biondi (philippe.biondiat_private) - Steve Bremer (steveat_private) - - or visit lids home , - http://www.lids.org/ - - And you can get help from the LIDS Mailing list at - http://www.lids.org/maillist.html - and the FAQ by Steve Bremer at - http://www.clublinux.org/lids/ - - If your want to make LIDS as module, say "M" here , or if you want to build it into - the kernel, say "Y" here. otherwise, say "N". - -Hang up console when raising a security alert -CONFIG_LIDS_SA_EXEC_UP - Saying yes will generate a security alert for each unprotected program - that is executed before LIDS is sealed (with lidsadm -I). - This can help a lot to check whether your boot sequence is secured. - This can also warn you if a weakness has been exploited and an - unprotected program has been added to the boot process. - - Saying yes increases security. - -Do not execute unprotected programs before sealing -CONFIG_LIDS_NO_EXEC_UP - This option makes LIDS refuse the execution of the unprotected programs - before it is sealed. Be aware that you can prevent the system from - booting with an incomplete lids.conf. - - Saying yes increases security. - - Warning: Selecting this may cause your system to fail to boot, you must - create proper ACLs to protect all the programs running before - sealing. So, if you got problem with booting, disable this option, - recompile and boot again. - -Enable init children lock feature -CONFIG_LIDS_INIT_CHILDREN_LOCK - Saying yes here will compile the necessary code for the - init children lock feature. You can then activate the feature with - lidsadm (+LOCK_INIT_CHILDREN). It will prevent anybody from killing - processes whose parent is init and which are running when you issue - the command. - - This mean that no one can stop them (denial of service) or even - reload them with a new configuration file (restart or kill -HUP). - - Saying yes and using it increases security. - - -Logging behaviour -CONFIG_LIDS_NO_FLOOD_LOG - If you say Yes here, LIDS will try not to flood logs with the - same message repeated a lot of times. - - Saying yes will increase security. - -Number of similiar log events to allow within a given interval(Experimental) -CONFIG_LIDS_FLOOD_EVENT_THRESHOLD - This is the maximum number of similiar events that LIDS will - log within the interval defined in: - CONFIG_LIDS_FLOOD_EVENT_INTERVAL - - This is to compensate for the problem of multiple different - LIDS alerts for "exec() before LIDS sealing" as well as - for other cases. - -Threshold interval period for the maximum number of LIDS events(Experimental) -CONFIG_LIDS_FLOOD_EVENT_INTERVAL - This is the interval in which we count the number of similiar - events that may be flooding the LIDS logs. - -Port Scanner Detector in kernel(NEW) -CONFIG_LIDS_PORT_SCAN_DETECTOR - If you say Yes here, LIDS will also build a port scanner detector in - kernel. When somebody uses a port scanner to scan your host, LIDS will - report it to you by logging the necessary message. It can detect many - scanners, including nmap, satan, sscan with many methods including half - open scanning. - - When you disable raw socket (disable sniffer) by LIDS, it can replace - the user space portscan detector, for it does not use any socket at all. - - Saying yes will increase security. - -Time between two logs -CONFIG_LIDS_TIMEOUT_AFTER_FLOOD - This is the minimum time (in seconds) allowed between two different - security alerts. When a security alert occurs, no more alerts will be - logged before expiration of this timeout. (Except the first alert, with - a flood warning). - -Allow switching normal/security mode -CONFIG_LIDS_ALLOW_SWITCH - If you say Yes here, you will enable the possibility to switch - LIDS on and off. - - Note: You must set a password with 'lidsadm -P' - - Saying no increases security. - -Restrict mode switching to specified terminal types -CONFIG_LIDS_RESTRICT_MODE_SWITCH - If you enable this option, mode switching will be only allowed - from specified terminal types. - -Allow mode switching from Linux Console -CONFIG_LIDS_MODE_SWITCH_CONSOLE - Allow mode switching from a Linux Console. - -Allow mode switching from serial Console -CONFIG_LIDS_MODE_SWITCH_SERIAL - Allow mode switching from a serial Console. - -Allow mode switching from a PTY -CONFIG_LIDS_MODE_SWITCH_PTY - Allow mode switching from a PTY. - -Number of attempts to submit password -CONFIG_LIDS_MAX_TRY - Here you put the number of tries you will allow before disabling the - switch capability for a while. - - The lower it is, the more secure the system will be. - -Time to wait after a fail -CONFIG_LIDS_TTW_FAIL - Here you put the time (in seconds) the switch capability will be - disabled when the authorised number of fails is reached. - - The higher it is, the more secure the system will be. - -Allow remote users to switch LIDS on/off -CONFIG_LIDS_REMOTE_SWITCH - Say Yes here if you want to allow users which are not logged - on through the console to be able switch LIDS on and off. - - If you have access to the console, you might disable this - option, so that a remote user can not disable LIDS, even - with the password. - - Saying no is more secure. - -Allow any program to switch LIDS on/off -CONFIG_LIDS_ALLOW_ANY_PROG_SWITCH - If you say Yes here, you will allow programs others than - /sbin/lidsadm to feed /proc/sys/lids/locks. - - Notes : * It is strongly recommended to leave this option - unmarked ! Don't say yes ! - * I don't know what it could be useful for :) - - Say no. - -Allow reloading config file when switched off -CONFIG_LIDS_RELOAD_CONF - Saying Yes here will compile the necessary code to reload the config - file. Each time you pass +RELOAD_CONF argument to lidsadm, LIDS reloads - /etc/lids.conf and re-reads dev/inode numbers of special programs - (/sbin/lidsadm and every program you allow to do something LIDS - forbids) - - If an error occurs during the reload phase, the kernel does not panic - as it does at startup, because it considers you see the error - immediately and correct it. - -Send security alerts through network -CONFIG_LIDS_SA_THROUGH_NET - Say yes here if you want to send LIDS security alerts to - a remote machine through the network, directly from the - kernel, without the help of any potentially corrupted - user space program (especially mailer programs) - You can send them via mail or via UDP datagrams to a - remote syslog, http POST, or anything else you can imagine. - - A pseudo scripting language a la expect is provided to - use some communication protocols (as the mail one). - - Below is a summary of the important parameters for the - connection. See their respective help section for more - help. - - You must provide - - the IP of the remote machine - - the TCP/UDP port for the connection - - If you choose to use the provided mailer script - - Name of the source machine - - Name of the sender - - Mail address of the receiver - - Subject of the mail - - If you choose to use your own script - (or the remote syslog one, provided) : - - Socket type (TCP/UDP) - - Path of the script - -Hide klids kernel thread -CONFIG_LIDS_HIDE_KLIDS - If you say yes here, the klids kernel thread won't appear in - /proc (thus neither in ps nor in top, nor in anything else) - and its network connection won't appear in netstat. - - Moreover, klids network errors (can't connect, etc.) will - be silently ignored instead of being logged in syslog. - -Number of connection tries before giving up -CONFIG_LIDS_NET_MAX_TRIES - How many times klids will try to send the security alert, if - it can't connect (you forgot a firewall ? :) ), or if there - is a protocol error (remote sendmail doesn't accept your mail ?). - After this number of tries, the message is deleted, even - if it was not send (we can imagine that, for some unknown - reason (protocol error, defectious IP stack on the road,..) - the message can't be send and block the remaining of the - queue). - - If you don't want to loose any messages, put a big number - of tries here, and give a reasonnable sleep period. - -Sleep time after a failed connection -CONFIG_LIDS_NET_TIMEOUT - When klids fails to send the security alert, how many seconds - will it sleep before retrying ? - -Message queue size -CONFIG_LIDS_MSGQUEUE_SIZE - The security alerts are stored in a message queue. Give - the number of messages that could be queued before loosing - new messages here. - -Use generic mailer pseudo-script diff -Nru a/security/lids/Config.in b/security/lids/Config.in --- a/security/lids/Config.in Wed Nov 6 17:19:42 2002 +++ /dev/null Wed Dec 31 16:00:00 1969 @@ -1,56 +0,0 @@ -# -# Config.in for LIDS -# - -if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then -if [ "$CONFIG_SYSCTL" = "y" ]; then - mainmenu_option next_comment - comment 'Linux Intrusion Detection System' - #bool 'Linux Intrusion Detection System support (EXPERIMENTAL)' CONFIG_LIDS - tristate 'Linux Intrusion Detection System support (EXPERIMENTAL)' CONFIG_LIDS - if [ "$CONFIG_LIDS" != "n" ]; then - - comment 'LIDS features' - int ' Maximum protected objects to manage' CONFIG_LIDS_MAX_INODE 256 - int ' Maximum ACL subjects to manage' CONFIG_LIDS_MAX_SACL 256 - int ' Maximum ACL objects to manage' CONFIG_LIDS_MAX_OACL 256 - int ' Maximum protected proceeds' CONFIG_LIDS_MAX_PROTECTED_PID 256 -# bool ' Hang up console when raising a security alert' CONFIG_LIDS_HANGUP - bool ' Security alert when execing unprotected programs before sealing LIDS' CONFIG_LIDS_SA_EXEC_UP - if [ "$CONFIG_LIDS_SA_EXEC_UP" = "y" ]; then - bool ' Do not execute unprotected programs before sealing LIDS' CONFIG_LIDS_NO_EXEC_UP - fi - bool ' Attempt not to flood logs' CONFIG_LIDS_NO_FLOOD_LOG - if [ "$CONFIG_LIDS_NO_FLOOD_LOG" = "y" ]; then - int ' Authorised time between two identic logs (seconds)' CONFIG_LIDS_TIMEOUT_AFTER_FLOOD 60 - fi - - if [ "$CONFIG_PROC_FS" = "y" ]; then - bool ' Allow switching LIDS protections' CONFIG_LIDS_ALLOW_SWITCH - if [ "$CONFIG_LIDS_ALLOW_SWITCH" = "y" ]; then - bool ' Restrict mode switching to specified terminals' CONFIG_LIDS_RESTRICT_MODE_SWITCH - if [ "$CONFIG_LIDS_RESTRICT_MODE_SWITCH" = "y" ]; then - bool ' Allow mode switching from a Linux Console' CONFIG_LIDS_MODE_SWITCH_CONSOLE - bool ' Allow mode switching from a serial Console' CONFIG_LIDS_MODE_SWITCH_SERIAL - bool ' Allow mode switching from a PTY' CONFIG_LIDS_MODE_SWITCH_PTY - fi - int ' Number of attempts to submit password' CONFIG_LIDS_MAX_TRY 3 - int ' Time to wait after a fail (seconds)' CONFIG_LIDS_TTW_FAIL 3 - bool ' Allow any program to switch LIDS protections' CONFIG_LIDS_ALLOW_ANY_PROG_SWITCH - bool ' Allow reloading config. file' CONFIG_LIDS_RELOAD_CONF - fi - fi -# bool ' Port Scanner Detector in kernel' CONFIG_LIDS_PORT_SCAN_DETECTOR - - bool ' Send security alerts through network' CONFIG_LIDS_SA_THROUGH_NET - if [ "$CONFIG_LIDS_SA_THROUGH_NET" = "y" ]; then -# bool ' Hide klids kernel thread' CONFIG_LIDS_HIDE_KLIDS - int ' Number of connection tries before giving up' CONFIG_LIDS_NET_MAX_TRIES 3 - int ' Sleep time after a failed connection' CONFIG_LIDS_NET_TIMEOUT 30 - int ' Message queue size' CONFIG_LIDS_MSGQUEUE_SIZE 16 - fi - bool ' LIDS Debug ' CONFIG_LIDS_DEBUG - fi - endmenu -fi -fi diff -Nru a/security/lids/Kconfig b/security/lids/Kconfig --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/security/lids/Kconfig Wed Nov 6 17:19:42 2002 @@ -0,0 +1,271 @@ +# +# Kconfig for LIDS +# + +menu "Linux Intrusion Detection System" + +if EXPERIMENTAL && SYSCTL + +config LIDS + tristate "Linux Intrusion Detection System support (EXPERIMENTAL)" + help + LIDS - Linux Intrusion Detection System can let you protect + your linux kernel. + + In order to use LIDS, you need to download the lidstools first + from http://www.lids.org/ + + Please read help provided with each option carefully. At the end + of each option we indicate what answer will increase security. + Be aware that security always has side effects, and some + programs could break. + + If you have any questions about LIDS, mail to the authors : + Huagang Xie ( xieat_private) + Philippe.biondi (philippe.biondiat_private) + Steve Bremer (steveat_private) + + or visit lids home , + http://www.lids.org/ + + And you can get help from the LIDS Mailing list at + http://www.lids.org/maillist.html + and the FAQ by Steve Bremer at + http://www.clublinux.org/lids/ + + If your want to make LIDS as module, say "M" here , or if you + want to build it into the kernel, say "Y" here. otherwise, + say "N". + +if LIDS + +comment "Lids features" + +config LIDS_MAX_INODE + int "Maximum protected objects to manage" + default 256 + +config LIDS_MAX_SACL + int "Maximum ACL subjects to manage" + default 256 + +config LIDS_MAX_OACL + int "Maximum ACL objects to manage" + default 256 + +config LIDS_MAX_PROTECTED_PID + int "Maximum protected proceeds" + default 256 + +config LIDS_SA_EXEC_UP + bool "Security alert when execing unprotected programs before sealing LIDS" + help + Saying yes will generate a security alert for each unprotected + program that is executed before LIDS is sealed (with lidsadm + -I). This can help a lot to check whether your boot sequence + is secured. This can also warn you if a weakness has been + exploited and an unprotected program has been added to the + boot process. + + Saying yes increases security. + +config LIDS_NO_EXEC_UP + bool "Do not execute unprotected programs before sealing LIDS" + depends on LIDS_SA_EXEC_UP + help + + This option makes LIDS refuse the execution of the unprotected + programs before it is sealed. Be aware that you can prevent + the system from booting with an incomplete lids.conf. + + Saying yes increases security. + + Warning: Selecting this may cause your system to fail to boot, + you must create proper ACLs to protect all the programs + running before sealing. So, if you got problem with booting, + disable this option, recompile and boot again. + +config LIDS_NO_FLOOD_LOG + bool "Attempt not to flood logs" + help + If you say Yes here, LIDS will try not to flood logs with the + same message repeated a lot of times. + + Saying yes will increase security. + +config LIDS_TIMEOUT_AFTER_FLOOD + int "Authorised time between two identic logs (seconds)" + depends on LIDS_NO_FLOOD_LOG + default 60 + help + This is the minimum time (in seconds) allowed between two + different security alerts. When a security alert occurs, + no more alerts will be logged before expiration of this + timeout. (Except the first alert, with a flood warning). + +if PROC_FS + +config LIDS_ALLOW_SWITCH + bool "Allow switching LIDS protections" + help + If you say Yes here, you will enable the possibility to switch + LIDS on and off. + + Note: You must set a password with 'lidsadm -P' + + Saying no increases security. + +if LIDS_ALLOW_SWITCH + +config LIDS_RESTRICT_MODE_SWITCH + bool "Restrict mode switching to specified terminals" + help + If you enable this option, mode switching will be only allowed + from specified terminal types. + +if LIDS_RESTRICT_MODE_SWITCH + +config LIDS_MODE_SWITCH_CONSOLE + bool "Allow mode switching from a Linux Console" + help + Allow mode switching from a Linux Console. + +config LIDS_MODE_SWITCH_SERIAL + bool "Allow mode switching from a serial Console" + help + Allow mode switching from a serial Console. + +config LIDS_MODE_SWITCH_PTY + bool "Allow mode switching from a PTY" + help + Allow mode switching from a PTY. + +# endif LIDS_RESTRICT_MODE_SWITCH +endif + +config LIDS_MAX_TRY + int "Number of attempts to submit password" + default 3 + help + Here you put the number of tries you will allow before disabling the + switch capability for a while. + + The lower it is, the more secure the system will be. + +config LIDS_TTW_FAIL + int "Time to wait after a fail (seconds)" + default 3 + help + Here you put the time (in seconds) the switch capability will be + disabled when the authorised number of fails is reached. + + The higher it is, the more secure the system will be. + +config LIDS_ALLOW_ANY_PROG_SWITCH + bool "Allow any program to switch LIDS protections" + help + If you say Yes here, you will allow programs others than + /sbin/lidsadm to feed /proc/sys/lids/locks. + + Notes : * It is strongly recommended to leave this option + unmarked ! Don't say yes ! + * I don't know what it could be useful for :) + + Say no. + +config LIDS_RELOAD_CONF + bool "Allow reloading config. file" + help + Saying Yes here will compile the necessary code to reload + the config file. Each time you pass +RELOAD_CONF argument to + lidsadm, LIDS reloads /etc/lids.conf and re-reads dev/inode + numbers of special programs (/sbin/lidsadm and every program + you allow to do something LIDS forbids) + + If an error occurs during the reload phase, the kernel does + not panic as it does at startup, because it considers you see + the error immediately and correct it. + +# endif LIDS_ALLOW_SWITCH +endif + +# endif PROC_FS +endif + +config LIDS_SA_THROUGH_NET + bool "Send security alerts through network" + help + Say yes here if you want to send LIDS security alerts to a + remote machine through the network, directly from the kernel, + without the help of any potentially corrupted user space program + (especially mailer programs) You can send them via mail or via + UDP datagrams to a remote syslog, http POST, or anything else + you can imagine. + + A pseudo scripting language a la expect is provided to use + some communication protocols (as the mail one). + + Below is a summary of the important parameters for the + connection. See their respective help section for more help. + + You must provide + - the IP of the remote machine + - the TCP/UDP port for the connection + + If you choose to use the provided mailer script + - Name of the source machine + - Name of the sender + - Mail address of the receiver + - Subject of the mail + + If you choose to use your own script + (or the remote syslog one, provided) : + - Socket type (TCP/UDP) + - Path of the script + +if LIDS_SA_THROUGH_NET + +config LIDS_NET_MAX_TRIES + int "Number of connection tries before giving up" + default 3 + help + How many times klids will try to send the security alert, if + it can't connect (you forgot a firewall ? :) ), or if there + is a protocol error (remote sendmail doesn't accept your mail ?). + After this number of tries, the message is deleted, even + if it was not send (we can imagine that, for some unknown + reason (protocol error, defectious IP stack on the road,..) + the message can't be send and block the remaining of the + queue). + + If you don't want to loose any messages, put a big number + of tries here, and give a reasonnable sleep period. + +config LIDS_NET_TIMEOUT + int "Sleep time after a failed connection" + default 30 + help + When klids fails to send the security alert, how many seconds + will it sleep before retrying ? + +config LIDS_MSGQUEUE_SIZE + int "Message queue size" + default 16 + help + The security alerts are stored in a message queue. Give + the number of messages that could be queued before loosing + new messages here. + +# endif LIDS_SA_THROUGH_NET +endif + +config LIDS_DEBUG + bool "LIDS Debug" + +# endif LIDS +endif + +# endif EXPERIMENTAL && SYSCTL +endif + +endmenu diff -Nru a/security/lids/include/linux/lidsext.h b/security/lids/include/linux/lidsext.h --- a/security/lids/include/linux/lidsext.h Wed Nov 6 17:19:42 2002 +++ b/security/lids/include/linux/lidsext.h Wed Nov 6 17:19:42 2002 @@ -29,7 +29,7 @@ #define LIDS_STR(X) LIDS_STR2(X) #ifdef LIDS_DEBUG -#define LIDS_DBG(msg...) printk(KERN_DEBUG "LIDS." __FUNCTION__ ".l" LIDS_STR(__LINE__) ": " ##msg) +#define LIDS_DBG(format, args...) printk(KERN_DEBUG "LIDS.%s.l" LIDS_STR(__LINE__) ": " format, __FUNCTION__ , ##args) #else #define LIDS_DBG(msg...) #endif diff -Nru a/security/lids/klids.c b/security/lids/klids.c --- a/security/lids/klids.c Wed Nov 6 17:19:42 2002 +++ b/security/lids/klids.c Wed Nov 6 17:19:42 2002 @@ -456,7 +456,6 @@ init_waitqueue_head(&(lids_msgqueue[0].writeq)); init_MUTEX_LOCKED(&klids_sem); - DECLARE_COMPLETION(done); klids_wq = create_workqueue("klids"); INIT_WORK(&klids_work, (void *)(lids_klids_thread), NULL); diff -Nru a/security/lids/lids_exec.c b/security/lids/lids_exec.c --- a/security/lids/lids_exec.c Wed Nov 6 17:19:42 2002 +++ b/security/lids/lids_exec.c Wed Nov 6 17:19:42 2002 @@ -166,7 +166,7 @@ if(!bprm || !bprm->file) { printk("%s:BUG!\n",__FUNCTION__); return 0; } - LIDS_DBG("%s:##### pid %i exec [%s]\n",__FUNCTION,current->pid,bprm->filename); + LIDS_DBG("%s:##### pid %i exec [%s]\n",__FUNCTION__ ,current->pid,bprm->filename); dentry = bprm->file->f_dentry; /* check if this program is protected or not */ if (lids_check_base(dentry,LIDS_APPEND)) { _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Nov 06 2002 - 16:31:22 PST