Title ===== Mandrake 8.2 msec security issue Author ====== Spot spot @ getlinuxonline.com Affected ======== The msec security system in Mandrake 8.2 Download Edition, 8.2 Boxed Edition, and possibly other Mandrake 8.2 releases Effect ====== Default security settings leave users' home directories world readable. Description/Discussion ====================== I installed Mandrake 8.2 Download Edition on my laptop, adding 2 users during the install. All relevant errata updates were applied. Upon booting it up and logging in, I noticed that I was able to enter other user's home directories and subdirectories and read the files. Delving further into it, it was discovered that at least ~/tmp, ~/.ssh and ~/Mail were denied to the other user. The large majority of other subdirectories and files were allowed, including browser caches. The permissions were as follows: [spot@lap home]$ ls -l total 2 drwxr-xr-x 12 altspot altspot 1024 Jun 7 21:47 altspot/ drwxr-xr-x 13 spot spot 1024 Jun 9 13:26 spot/ The Mandrake Security aka msec level (as offered as the default choice during the install) is set at "Standard", described as in the Mandrake Control Center as "the standard security recommended for a computer that will be used to connect to the internet as a client". Doing more research into msec, I found this alternate description of the same level: "Level 2: Low. The increased security over level 1 is that msec provides more security warnings and checks. This level is appropriate for multi-user local use" (from http://www.mandrakesecure.net/en/docs/msec.php). Note that the 2 descriptions are quite different. msec is installed by defalt. Going through 3 installs, I was unable to find where to unselect it as an installed package. This behavior was confirmed with the help of other users via Usenet and IRC. Fresh installs were done, accepting the default, "Standard" security level with the same results. The behavior has also been confirmed with the Mandrake 8.2 Boxed Edition(retail). Earlier Mandrake versions (8.1 was the only one tested) don't seem to exhibit this behavior. I have not verified this personally, only via other user reports. In 2 cases this behavior did not show up when /home pre-dated a Mandrake 8.2 installation (was carried over from a previously installed version). msec even went as far as to undo changes I made as administrator of the machine: I chmod'd each user's home directory to 700. As it's a laptop, it gets shut down from time to time. Upon reboot, the permissions reverted to what they were before. msec referted the perms back to 755. This default is inherently insecure for obvious reasons. Further reading into the msec docs returned info that the perms would have been changed back after 4 am, when msec does it's checking. When security settings were manually changed, via the Mandrake Control Center(or typing in 'msec 3' via CLI), from the default "Standard" to "High", the next level up(aka 'msec 3'), I was still able to cd into another user's home directory, but received permission denied when trying to ls. Permissions with a setting of "High" showed thusly: [spot@lap home]$ ls -l total 2 drwx--x--x 12 altspot altspot 1024 Jun 9 14:45 altspot/ drwx--x--x 13 spot spot 1024 Jun 10 00:26 spot/ Now this is more like it should be. 711 is better, but 700 would be preferred. You still shouldn't even be able to cd into another user's home directory unless it's necessary for Apache access to a user's public_html directory or some such. Note: this is not the offered _default_ (aka "Standard" aka 'msec 2') security level. Vendor Contact ============== June 10, 2002 ~~~~~~~~~~~~~ Mandrake was contacted via email to qa @ mandrakesoft.com, the bug report address noted on their website at http://www.mandrakesoft.com/company/contact/feedback. June 11, 2002 ~~~~~~~~~~~~~ Sent a copy of same to security @ linux-mandrake.com (address found at http://www.linux-mandrake.com/en/security/) After numerous attempts, I was unable to get permissions to post to the Mandrake Bugzilla database - receiving "Access Denied. You are not allowed to post a bug." even after creating an account and following the instructions at the site (https://qa.mandrakesoft.com/cgi-bin/enter_bug.cgi). Several queries to the Mandrake Bugzilla database resulted in finding no reported behavior similar to that described above. A manual search through the security discussion archives (http://www.mandrakesecure.net/archives/discuss/) resulted in finding this thread (http://www.mandrakesecure.net/archives/discuss/2002-02/msg00277.html). The observations weren't quite the same, nor were any conslusions formed. I was unwilling to sign up for yet another forum ("Mandake Expert"). June 12, 2002 ~~~~~~~~~~~~~ Mail to security @ linux-mandrake.com bounced back - resent June 13, 2002 ~~~~~~~~~~~~~ Mail to security @ linux-mandrake.com bounced back again - resent again Attempted once again to post to the Mandrake Bugzilla database, once again received "Access Denied" June 16, 2002 ~~~~~~~~~~~~~ Mail to security @ linux-mandrake.com bounced back yet again June 17, 2002 ~~~~~~~~~~~~~ As of this date, no response from Mandrake Solutions/Workarounds ===================== Until this is acknowledged/handled by Mandrake, admins should use the Mandrake Control Center, security settings section, and make sure the level is set to at least "High", or manually enter 'msec 3' via CLI, not the default, "Standard" aka 'msec 2', security level. The msec package can also be removed entirely (after the system is installed) and perms set manually after that. Author Statement ================ Many, many thanks to the denizens of alt.os.linux.mandrake and getlinuxonline.com for their help in researching this. Mandrake did not make it a simple process to attempt to communicate this issue to them. Mandrake is, by far, the choice for a vast number of new linux users due to it's ease of installation and excellent hardware detection. I can't imagine many new users, installing Mandrake [linux] for the first time (and hearing how secure linux is out of the box) would be aware that it's even a problem, much less know how to fix it. "Standard" aka 'msec 2' is the default offered security level. There is no way a new user would see it. This permission problem would remain until discovered in some possibly embarrassing, dangerous, or costly manner - especially since a) it's described as appropriate security and b) since even if the permissions are manually changed, msec reverts them unless the msec level is also manually changed via CLI or via the Mandrake Control Center, or the msec package is removed entirely. One problem seems to be the communication of the security settings to a user/admin. The Mandrake Control Center only has 3 level settings, and those settings are described quite differently fom their corresponding CLI msec levels(of which there are 6). I find it rather disconcerting that the offered default, "Standard"(aka 'msec 2'), setting is so insecure, and that it is not at all appropriate for the system envisioned for users of that security level, described by Mandrake as "appropriate for multi-user local use". This certainly appears to be a flaw in 8.2's implementation of msec, as reports show that the same behavior isn't exhibited in earlier versions.
This archive was generated by hypermail 2b30 : Tue Jun 18 2002 - 15:00:15 PDT