Mark McLoughlin markmc@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