desktop security questions

[Jonathan Blandford]

Mark McLoughlin <markmc at redhat.com> writes:

> Hi,
> 	So, I was just looking over George Lebl's desktop security paper for
> GUADEC[1] and I realised that when talking about desktop security we
> make a lot of assumptions about what we mean by security.

Good mail.  I'm not 100% sure what the goal here is, but I'll try to
follow up.

> 	Given that designing secure applications/systems is all about trade
> offs between the risks to the application and the cost of the possible
> countermeasures, you need some sort of basic framework for making those
> tradeoffs.
> 
> 	Here's the kind of thing I'm thinking of:
> 
>       * What can go wrong/what are we trying to prevent/risks? 
>               * Loss of data
>               * Disclosure of private data/loss of privacy
>               * Denial of service
>               * Interruption of work/reduced productivity

Another possible risk is identity masquerading (eg. sending a bomb
threat from another persons email account.)  There's also a ranking of
the severity of these.  They're all bad, but the last two are less bad,
as they diminish your experience and don't necessarily cause
irreversible harm.

We should also add that we are trying to protect the whole ecosystem as
much as possible.  That is, it's bad if an attacker gains the ability to
run a process as an unprivileged user on a box even if it takes negligible
resources from that box.

>       * What may cause the above to come about/threats? 
>               * Escalation of privileges to an attacker
>               * Execution of arbitrary commands specified by an attacker
>               * Ability for an attacker to force the program into
>                 monopolising system resources (cpu, memory, file
>                 descriptors, ports, hard disk space)
>               * Ability for an attacker to cause a program to abort in
>                 an unrecoverable way
>               * Ability for an attacker to snoop a user's actions

 * Ability for the attacker to trick the user into doing something.

>       * What are our assumptions? 
>               * The attacker can not have root access (i.e. any
>                 countermeasures to this threat would be futile)
>               * Our user is not technical and does not need to
>                 understand the threats to the system (although they do
>                 implicitly understand the risks)
>               * (Deployment environment assumptions)

 * Any solution that puts the burden of determining risk on the user is
   a non-solution?

>       * What are our goals? 
>               * Provide a system whereby the user can easily and safely
>                 get their work done
>               * Ensure the privacy and integrity of a user's data

No discussion of a process to reach these goals.  Is that an exercise
for the reader? (-:

Thanks,
-Jonathan