Date: Mon, 17 Jun 2002 17:35:28 -0400
From: Spot <spot@getlinuxonline.com>
To: bugtraq@securityfocus.com
Subject: Mandrake 8.2 msec security issue
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.
