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 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 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
