[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: desktop security

Moin Daniel!
Daniel Cardenas - AZ schrieb am Freitag, den 30. April 2004:

> There are a bunch of other simple changes we could try for example
> >>soften the security model.   Debian does a bunch of things to prevent a 
> >>normal user from abusing the system.  Details: root can't access the 
> >>screen without executing xauth (blah) command.  On a single user system 
> >>is this desired?  Perhaps we could eliminate the need to execute xauth.  
> >>   
> >>
> >
> >OH MY GOD! Are you serious? I already see the DAUs swearing at their
> >Linux box just because they accidentally screwed it.
> >
> >The Linux/Debian security model isn't sth. which is just there for fun
> >or to annoy users. When you soften such a fine system of privileges you
> >would negate one of Linux' greatest benefits: Security and Stability!
> >
> > 
> >
> Perhaps soften the security model isn't the right wording.  I saw a 
> desktop wiki page, can't find it now, that listed things that can be 

Martin: what about adding some URLs to the footer of the mails on this

> done to improve security for the user, for example allow accesses to 
> devices.  Debian security is currently very rigid designed for a 
> concurrent multi-user system.  On a desktop system, usability 
> improvements maybe more important than securing the system from another 
> user, since there typically isn't another user. 

This may be the right time to remember a (not existing yet) package
"user-friendly" which should do such things. I dreamed of a tool and a
simple infrastructure to realize following:

 - be executed by apt after the package installation
 - be executed by the user when he needs it

The tool would allow user/admin to configure the level of the
"paranoia vs. relaxed access", level of "saved space vs. installed docs"
or "space vs. installed extra packages" etc. The idea was 

a) to work around limitations caused by our current package
relationships (eg. install localisation packages depending on locale and
installed packages, eg. OpenOffice, Mozilla, KDE-i18n packs, or compile
and install kernel modules after the source was installed by dpkg, etc.) (*)

b) automate parts of configuration that many users (especially desktop
users) do, like adding the new users to new device groups or adding sudo
commands for special apps.

(*) The backend may work like in my module-assistant packages: control
scripts that watch for conditions and when they are fullfilled, some
configuration part is executed, eg. if kernel 2.6 has been installed,
some extra packages may need "dpkg-reconfigure ..." calls to improve

Wie man sein Kind nicht nennen sollte: 
  Mike Käfer 

Reply to: