Re: Lockdown stuff



We (Ximian, Novell, whatever) are also definitely interested in getting
lockdown infrastructure in place as soon as possible also, and for the
time being, at least, I'm the point man here for us.  Brief intro out of
the way...

On Wed, 2003-10-08 at 04:31, Alexander Larsson wrote:
> In general, I think your proposal is way too fine grained. A sysadmin
> that wants to lock down a box for some specific usage has to do a *lot*
> of work figuring out which of the lockdown keys to enable, and chances
> are high that he didn't think of some way to work around the
> configuration, making the box not locked down. 

Complete agreement.  I think we want to identify what lockdown means to
various target audiences, what features they will want to eliminate, and
provide the simplest way to get to that point -- identify broad
behavioral categories, rather than specific features, and let people
modify or disable those.

> Some of the keys you proposed can be configured in such a way that they
> make zero sense (allow cut+paste, but not copy?), and some things are
> better locked down in other ways (such as filesystem permissions). Many
> of the keys are such that any working/useful configuration of them make
> nautilus pretty much useless, and a better way to do the lockdown would
> probably be to disable nautilus. 

Filesystem permissions would definitely have to play a role in any
seriously hardened configuration, but I don't think that just because
things -can- be handled with the filesystem necessarily implies that we
shouldn't provide potentially overlapping functionality, perhaps less
secure by design, using lockdown keys and GConf.

(As Havoc said in another mail, think padded room.)

For instance, many people seem interested not in a truly hardened,
locked machine, e.g. a public kiosk, as much as a dramatically
simplified interface for a specific task.  The idea is then not
necessarily to make things impossible to do, as much as eliminate
distractions to the tasks you -do- want accomplished.

> I think a better approach to the lockdown problem is to sit down and
> talk to people who want to use lockdown and see what they really want to
> accomplish, then sit down and figure out a few higher-level lockdown
> operations that we implement throughout the desktop and that allows all
> the interesting policies to be implemented. This will allow mortal
> sysadmins to figure out how to set this up, and it will probably make
> the lockdown mode work better since the people who know the software
> best (the developers) will pick the feature details for a particular
> lockdown policy. It will also make the lockdown keys work across
> upgrades in a way that lowlevel 'disable-this-menu-item' keys won't. We
> probably won't be able to make a few high level policy settings do
> everything, so we might need to add a few lowlevel keys for those
> special-case situations where we can't get a sane highlevel policy that
> works for everyone.

I would strengthen your first claim and argue that it's not just a
better approach, as much as an absolute requirement, to sit down and
figure out what actual consumers of lockdown want to use it for before
we go anywhere productively on this.

Also, good point on the upgrade path.

Ian




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