Mailinglist Archive: opensuse-security (601 mails)

< Previous Next >
Re: [suse-security] SuSE security reputation, etc..
  • From: Roman Drahtmueller <draht@xxxxxxx>
  • Date: Thu, 3 Aug 2000 10:46:59 +0200 (MEST)
  • Message-id: <Pine.LNX.4.21.0008031015520.7754-100000@xxxxxxxxxxxx>
> % On the other side, Linux distributors could do even better. My wishlist
> % for Suse:
> % - configure security level (like harden_suse questions) with yast, and
> % make it more granular.
>
> Great idea.

We see that there is a narrow path between the resulting complexity of a
more detailed and granular configuration tool on the one side and the
user's skills (plus patience and time) to use it on the other side. If a
user can answer all detailed questions, he's probably capable of fixing
unwanted configuration items himself. By consequence, the configuration
can't exceed a certain level

>From this standpoint, the existing system (/etc/permissions / chkstat /
yast / harden_suse for the truly paranoid) surely has its advantages - it
needs more consistency and completeness though. We're working on it.


> % - by default, no shell user should be allowed to log in to ftp/telnet/pop
> % using the same password or at all
>
> Here's what throws me. I understand you to say that the default should
> be for a console-only system. Is that what you meant?? I also don't
> know what you mean by "same password"...

This is a no-go. By default, a SuSE distribution doesn't have any users
with a password after the installation, and only root can access the
machine. Since it is generally considered to be a bad idea to log on as
root without encryption, root login is only possible on the console and
via ssh. If you add users and issue passwords, you usually expect them to
log on. If we disable this possibility by default, we remove what people
expect when they use a network transparent O/S.


> % - have an installation option, that compares installed packages versus
> % ftp.suse.com and lists known vulnerabilites and available fixes, and does
> % updates on request
>
> That would be nice, too :-)

Yes, indeed. There are many problems to face: Let rpm work flawlessly, let
the tool work seamlessly with the servers, in short: Do everything
necessary that the system works. Yet, there are still situations where the
upgrade of a package may fail because local configuration changes have
been made. In this case, we'd have to blame it on the administrator. I
must admit that I don't like this idea.
We're thinking of a semi-automatic solution.

> %
> % I think, that a lot of security can be gained my making defaults more
> % secure, or easy, selectable installation options. Few systems get the
> % attention, that they should ..
>
> Yep. Few users, me included, even know all of the places to look, much
> less have the time to go and get updated packages and install them and
> make sure they really don't break anything else...

Agreed. I think you see the trade-off btw. secure configuration and the
ease of use.

> % Len Rose wrote:
> %
> % > http://www.abcnews.go.com/sections/tech/FredMoody/moody.html
> % > It really sucks that SuSE wasn't even mentioned.

:-) Thank you, Len, for providing the link to the page.

Roman.
--
- -
| Roman Drahtm├╝ller <draht@xxxxxxx> // "Caution: Cape does |
SuSE GmbH - Security Phone: // not enable user to fly."
| N├╝rnberg, Germany +49-911-740530 // (Batman Costume warning label) |
- -


< Previous Next >
Follow Ups
References