desktop security questions

[Mark McLoughlin]

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.

	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
              * ...
        
      * 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
              * ...
        
      * 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)
              * ...
        
      * 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
              * ...


	Any thoughts? Useful or not? Feel free to expand[2] the "..." bits.

Cheers,
Mark.

[1] - See http://2004.guadec.org/schedule/profiles.html

[2] - Red Hat people edit the SecureDesktopQuestions wiki page, everyone
      else just reply to the list (yes, that sucks and, yes, we'd really
      like to have an external wiki)

[Jonathan Blandford]

Mark McLoughlin <markmc(a)redhat.com&gt; 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

[Richard Li]

On Tue, Jun 15, 2004 at 12:58:46AM -0400, Jonathan Blandford wrote:
>  Mark McLoughlin <markmc(a)redhat.com&gt; writes:
>  >
>  > 	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. 
On a different but related note, protecting the whole ecosystem
entails different types of defenses. Bruce Schneier lists three types:
prevention, detection, and response. So, in Jonathan's example above,
there are three kinds of questions that the ultimate solution can
choose to provide:

1. What does the desktop do to prevent identity masquerading?
2. Once someone has stolen by identity, what does the desktop do to
let me know this has happened?
3. Once I figure out it's happened (via my own intuition or by some
notification mechanism), how does the desktop help me recover?

Another example: I've read that a lot of spam is sent by unwitting
Windows users. Microsoft is trying to improve security with efforts
such as the firewall in SP2. Something that could also be useful could
be something that sensed a lot of SMTP traffic and reported it: "Your
desktop is sending a very large quantity of email. This could indicate
that your machine has been infected with a malicious program. Go to
this URL for more information."

>  >       * 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 
Also:

Detect any violation of my data integrity/privacy.
Recover from violations of my data integrity/privacy.

Richard