[Cooker] RE: multiple msec bug reports and contributions
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) One thing, I have to apologize (to you and to myself) is for spending effort reporting so many bugs that were already fixed in cooker versions of msec. However, I do have to complain *LOUDLY* that you know of so many bothersome bugs and yet have not released a Bug Advisory or an Update to Mandrake 8.2 (the current release) for such a crucial package. Like I said in my earlier e-mail, something that is going to greatly change how the system is configured and potentially overwrite other configuration (from cron), needs to be very well constructed and very well documented. There have been several reports of the above bug (chage parsing problem for webmin users) reported to the [EMAIL PROTECTED] list in the past couple months. These are real users who are wasting time because of the lack of a Bug Advisory. For the most recent see: http://www.mandrakesecure.net/archives/discuss/2002-08/msg00029.php More musing: I wouldn't feel comfortable taking the msec package from cooker and installing it on a production 8.2 system. Especially because msec puts its fingers into the system in so many places, I would want an msec package Quality Assured to work with the system I'm installing it on. I also would want to prevent grabbing new, untested, development code. (I don't think msec has development and stable branches.) Posting Bug Updates that fix big problems and that have gone through QA is important for a linux distribution and the Right Way (tm) to get bothersome bugfixes out to the users. Red Hat is quite good about this, releasing RHBA Red Hat Bug Advisories in addition to their RHSA Red Hat Security Advisories. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Frederic Lepied Sent: Sunday, July 28, 2002 3:35 PM To: David Harris Cc: [EMAIL PROTECTED]; Florin Grad; [EMAIL PROTECTED]; Vincent Danen Subject: 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
[Cooker] resend: multiple msec bug reports and contributions
This message didn't go through to cooker the first time, so this is a resend. Yoann has already gotten back to me and forwarded the bug report onto Florin Grad [EMAIL PROTECTED], but I just wanted this to get archived here and perhaps help others from having to hunt down the same bugs. I'd also love to start a discussion on msec's community responsibility to be thoroughly documented, as I talk about in my theory/musing section below. :-) David -Original Message- From: David Harris [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 6:34 PM To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: multiple msec bug reports and contributions 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) 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. (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. (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. (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!) 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. (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 (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. (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. (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. (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
