"David Harris" <[EMAIL PROTECTED]> writes: > Hello, > > I'm sending this to: > [EMAIL PROTECTED] -- you are the packager of the msec package > [EMAIL PROTECTED] -- you are the only author listed of the msec > package > [EMAIL PROTECTED] -- bug reporting list (bugzilla seems dead and > was a royal pain to get bug posting access to)
Many thanks for your bug report. > I spent the better part of a week picking msec apart to fully understand > it. In doing this, I found a number of bugs in the code and in the > documentation. They are included below. > > First, some of my theory/musing about msec. This may help you know where > I'm coming from with some of the bugs. My impression of msec mainly > relates to the lack of documentation. Here's what I have to say about > this: > > (a) Msec has a high community responsibility to be thoroughly documented > and easy to understand. This is because msec overwrites files and > settings owned by other packages. When using msec, an administrator has > to know to not directly manipulate the settings that msec will > overwrite, and the administrator must be informed of the proper msec way > to configure this setting or override the default msec setting. You are right. Here is the solution I have implemented in 0.30: if the sysadmin augments the security, msec will not lower it if called without argument (in the hourly cron for example) but it will lower the security if told explicitly to change the security level by giving the security level as an argument. > (b) The documentation that comes with the msec package is lacking. > > (c) The best documentation I found wasn't even part of the msec package: > http://www.mandrakesecure.net/en/docs/msec.php This documentation was > also lacking in some areas (see my bug report). This documentation > should be improved and included with msec. I have improved it in 0.30. > (d) Msec has a high community responsibility to be easily override-able, > because it overwrites files and settings owned by other packages. > Unfortunately, it is not a particularly straightforward process to > override msec. One must translate descriptions in the documentation and > the mseclib function names (which really should be given in the > documentation). And having an end-user write a python library file is > non-straightforward. All the settings should be in an easy-to-understand > configuration file. Have you tried man mseclib ? All the functions are described. > (e) I was forced to spend a better part of a week doing the research on > msec that resulted in the below bug reports because of the lack of > documentation. I installed Mandrake Linux an a production servers and > had some msec issues. (Example: No documentation told me that with msec > level 4 and above, non-root users could not use ssh unless they were in > the ntools group. This would have been *extremely* helpful to know!) corected in 0.30 (in security.txt) > Now the bugs and contributions. Here is a list of what I've found and > attached: > > (1) Document with a list of bugs and contributions > (david_harris_020723_msec_bugs.doc.gz). > > This is the attached in HTML saved from MS Word (yes, yes, I know) and > then gzipped format. (I started with a word document to have formatting > control and I've embedded a few tables and such.) > > Also available are: > http://www.davideous.com/misc/david_harris_020723_msec_bugs.doc > http://www.davideous.com/misc/david_harris_020723_msec_bugs.html > > Here is a breakdown by type: > > 6 code bugs > 3 documentation bugs > 1 documentation contribution > 4 configuration ease/flexibility issues > > Here is an outline: > > (1.a) Bug 1, code: the pattern matching in allow_root_login(arg) in > /usr/share/msec/libmsec.py doesn't work if the PermitRootLogin statement > is not already in the /etc/ssh/sshd_config file. already corrected in 0.25 > (1.b) Bug 2, code: msec accept_icmp_echo(arg) in > /usr/share/msec/libmsec.py only sets /etc/sysctl.conf and doesn't make > sure that /etc/sysctl.conf (or preferably just these values) is loaded > into the actual kernel sysctl's done in 0.30 > (1.c) Bug 3, code: In /usr/share/msec/promisc_check.sh logging is never > done to a TTY because the configuration variable TTYLOG_WARN is used > instead of the correct TTY_WARN. done in 0.30 > (1.d) Bug 4, documentation: The feature of writing data to > /var/security.log is presented as a configuration option. It is not a > configuration option. The scripts that write to /var/security.log write > to the location regardless of any configuration. It only matters if > these scripts are running. Where have you seen this ? > (1.e) Bug 5, documentation: In > http://www.mandrakesecure.net/en/docs/msec.php "Warnings in syslog" has > been added to the first table. The feature is really the same as > SYSLOG_WARN in the second table. It shouldn't be listed twice. Right. Vincent can you correct ? > (1.f) Bug 6, code: In enable_ip_spoofing_protection() in > /usr/share/msec/libmsec.py, the net.ipv4.conf.all.rp_filter setting is > only set to 1 when enabling spoofing protection and never set back to 0 > when disabling spoofing protection. done in 0.30 > (1.g) Bug/Enhancement Request 7, configuration ease/flexibility issue: > The configuration enable_ip_spoofing_protection(arg, alert=1) sets two > different "anti-spoofing measures" that may be needed separately in some > cases. done in 0.30 > (1.h) Bug 8, configuration ease/flexibility issue: Overriding the > default configuration for promisc_check.sh is a real pain and requires > calling two independent functions to set one setting. Each function is > useless without the other. They should be one function. added to todo > (1.i) Bug 9, documentation: The documentation for the default settings > for allow_x_connections() is incorrect. added to todo > (1.j) Bug 10, configuration ease/flexibility issue: The setting for what > msec levels allow "." in $PATH is hard coded into /etc/profile.d/msec.sh > and /etc/profile.d/msec.csh, which get the msec security level from the > SECURE_LEVEL variable in /etc/sysconfig/msec. This means this setting > can't be overridden. The creation of /etc/issue and /etc/issue.net is > also hard coded in /etc/rc.d/rc.local and also can't be overridden. added to todo > (1.k) Bug 11, code: There is a race condition with the /var/run/msec.pid > lockfile in /usr/sbin/msec. added to todo > (1.l) Bug 12, configuration ease/flexibility issue: Many of the checks > will not be performed unless enable_security_check(1) is set and > CHECK_SECURITY is true. For those who are considering overriding the > default levels, this should be pointed out in the documentation. The > CHECK_SECURITY option seems somewhat pointless as it is duplicated by > enable_security_check(). added to todo > (1.m) Contribution 1, documentation: msec_pem_to_table.pl -- A script > that creates an HTML summary report of the file permission settings for > different security levels so that the settings are easy to compare. > Currently, this information is stored by msec in a different file for > each level (without any summary documentation!), so it is hard to > compare the levels and know which one does what. thx > (1.n) Bug 13, code: In /usr/share/msec/libmsec.py in function > password_aging(), the code that parses the output from the chage command > dose not accept negative "Maximum" settings. Somehow (I have no idea!) I > got a user on my system, "bob", that had -1 for the Maximum setting and > msec started throwing fatal errors. already corrected in 0.20 (this happens with users created by webmin) -- Fred - May the source be with you
