[Cooker] RE: multiple msec bug reports and contributions
On July 28 2002, Frederic Lepied wrote: Many thanks for your bug report. I hope it has been helpful. Sorry for taking so long to get back to you. (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. The solution you describe in 0.30 solves half the problem. I had the most trouble with msec when I wanted to remove a security precaution that I deemed un-needed. For example, I restored /etc/securetty so that I could login from the system console as root. Then, an hour later, mysteriously, the entries I added to /etc/securetty were gone. This kind of thing can be frustrating to a sysadmin especially on a default install where you are forced to use msec. There needs to be a comprehensive list of what settings in what files the sysadmin shouldn't touch directly. (Preferably with comments in those files, or the files set to 444 mode or something.) This documentation needs to be presented to the sysadmin clearly, and early. I'd prefer having this told to me when I'm configuring msec in the install. (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. Yes, I read mseclib. However, the names/descriptions of the functions in mseclib didn't directly match the names/descriptions in the other documentation. Stuff like Deny Services is really authorize_services(arg). And Warnings in syslog is really set_security_conf(SYSLOG_WARN, value). IMHO, the other documentation really should say something like to override, use the blah_blah_blah() function from mseclib. Making overriding msec as trivial as possible is Very Important. I hope the documentation has been much improved, as you say. Having a python library is somewhat of a hack. Users don't want to have to think about python. It also locks you into specific function names. (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 ? http://www.davideous.com/misc/david_harris_020723_msec_bugs.html says: begin snip Bug four Component: msec 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. These are the scripts that write to /var/security.log: /usr/share/msec/promisc_check.sh /usr/share/msec/diff_check.sh /usr/share/msec/security_check.sh If you look closely you will notice that there is no branching to make it optional. Here is how the documentation seems misleading: In http://www.mandrakesecure.net/en/docs/msec.php, Warnings in security.log is listed along with all the other configuration options. In /usr/share/doc/msec-0.19/security.txt the feature, Warning in /var/log/security.log is listed along with all the other features. I consider this a bug, because I spent some time trying to hunt down where I could customize this behavior of syslog logging in man mseclib only to find that it wasn't settable (like everything else listed along with it). Notice that in the table listed under Doc of the rewritting in python: in /usr/share/doc/msec-0.19/README, the feature Warnings in security.log is not listed, but for some reason it shows up in the same table in http://www.mandrakesecure.net/en/docs/msec.php. end snip (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
[Cooker] Re: multiple msec bug reports and contributions
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
