Mandrake 8.2 msec security issue

[Spot <spot () getlinuxonline com>]

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.