[TriLUG] Getting SSH to work at MSEC level 4 in Mandrake

Aaron S. Joyner aaron at joyner.ws
Mon May 3 19:29:57 EDT 2004


First off, Thanks for the full run-down Tanner.  It was nice to be able 
to read that without having to actually jump through the hoops to get to 
that point in an install.

> I'm curious as to how much of that your friend actually read.  It 
> seemed by
> your description that he was just setting up a standard client, not a 
> server. 

He was setting up a server, for development purposes, behind a 
firewalled network, that wouldn't see much real internet exposure other 
than (maybe) Apache.  Knowing the user, he probably glossed over the 
settings and chose the one that said, "Good enough to use as a server".  
Which sounds right, and is not a bad wording from a practical 
perspective, but caused him some trouble in his particular edge-case 
scenario.  I really like the slider idea you proposed, I think that 
would be a good step in the direction of making the trade offs more 
clear.  How do we go about bringing this thread to the attention of the 
Mandrake development folks, in hopes of affecting some real change?  :)

> Note, btw, though, that while frustrating at times, the periodic security
> checks are actually a *good* thing.  [etc, to end of paragraph]

I wouldn't argue that at all.  The checks are a very good thing, and a 
very nice feature to have so easily available as a single-click 
setting.  Unfortunately though, one of the side effects to that nice an 
integration is it diverges the distribution a little farther from "the 
norm", and generally increases the learning curve for experienced 
users.  On the other hand, once you figure out how the guts of the 
built-in systems work, they tend to grow on you, and improve your 
understanding of "how good things can be".  Developing a preference for 
or against that type of divergence is left as a exercise to the reader.  :)

Aaron S. Joyner


Tanner Lovelace wrote:

> Aaron S. Joyner said the following on 5/3/04 11:41 AM:
>
>> I find it unfortunate that the installer presents security related 
>> options with out dire warnings about the compatibility and feature 
>> trade-offs associated with each "Security Level".  Unfortunately, new 
>> users are often lulled into thinking "Sure, I want more security" so 
>> they choose a setting that is unfortunately higher than their ability 
>> to competently run.  The net result often being that they are turned 
>> off by "this linux thing" and give up, going back to their 
>> comfortable Windows world.  I'm not suggesting that these security 
>> related enhacements are in any way bad, but the installer should 
>> emphasise the inherent security of the lower levels compared to other 
>> OSes, and the potential pitfalls associated with the higher level of 
>> security.  I imagine the information is buried in the documentation, 
>> and perhaps there is a link to that documentation on that page - not 
>> having completely installed Mandrake before myself, I just don't 
>> know.  But regardless of the level of information present, it appears 
>> to me that it's not enough.  :)
>>
>> Aaron S. Joyner
>
>
> Just as an FYI, this is what it says when you select a mandrake 
> security level:
>
>   The Security Level menu allows you to select one of the six 
> preconfigured
>   security levels provided with msec. These levels range from poor 
> security and
>   ease of use, to paranoid config, suitable for very sensitive server
>   applications:
>
>   Poor: This is a totally unsafe but very easy to use security level. 
> It should
>   only be used for machines not connected to any network and that are not
>   accessible to everybody.
>
>   Standard: This is the standard security recommended for a computer 
> that will
>   be used to connect to the Internet as a client.
>
>   High: There are already some restrictions, and more automatic checks 
> are run
>   every night.
>
>   Higher: The security is now high enough to use the system as a 
> server which
>   can accept connections from many clients. If your machine is only a 
> client on
>   the Internet, you should choose a lower level.
>
>   Paranoid: This is similar to the previous level, but the system is 
> entirely
>   closed and security features are at their maximum.
>
> I'm curious as to how much of that your friend actually read.  It 
> seemed by
> your description that he was just setting up a standard client, not a 
> server.
> Based on that and the above description I would pick the "Standard" 
> level of
> security.  I will admit that when they say "poor security and ease of 
> use"
> it isn't quite obvious that they're equating poor security is the 
> *same* as
> ease of use (and that higher security should be equated with harder to 
> use).
> People who do a lot with security already know about this tradeoff and so
> tend to pick whatever is appropriate but a new user doesn't have that
> background.  Perhaps a slider like this one would be easier?
>
> Less Security                                       More security
>      |------------|------------|------------|------------|
> Easier to use                                       Harder to use
>
> That would make the tradeoff clearer.
>
> Note, btw, though, that while frustrating at times, the periodic security
> checks are actually a *good* thing.  Say, for instance, your box gets
> broken into and some things get changed to allow easier access to it.
> It's entirely possible that the next time msec runs it will close down
> whatever was changed.  Also, for the higher security levels, having a
> policy of turning everything off and only enabling what should be turned
> on is very definitely the "right way"(tm) to do things from a security
> standpoint.
>
> One thing I've been kicking around is putting together a presentation
> on msec and various other mandrake security options (the secure kernel
> patches it uses too).  Would there be any interest in a presentation
> about this? (There's probably not enough material to do a full class,
> but there's more than enough for a simple presentation.)
>
> Cheers,
> Tanner





More information about the TriLUG mailing list