[cap-talk] Is allowing malware 'private' storage harmfull?

[Rob Meijer]

In my MinorFs project, I implement private storage for n-th claim
persistent processes. For 'good' software that is clearly a good thing,
but is there a relevant flip side to this?

1) Alice@/bin/banking-application:1
2) Alice@/home/alice/Download/Readme.TXT.malware.exe:1

( For those of you wondering about the notation,
  'Alice@/bin/banking-application:1' means: the process running
  under the uid of Alice that has its executable located at
  /bin/banking-application, and holds the 1st slot of this combination.
)

It is clear to see that the fact that 1 can keep its data private from all
other processes run by alice, including 2 is a good thing.
However, currently MinorFs provides the exact same possibilities to 2, so
that the malware would be able to hide data from all other processes run
by Alice.
Would there be any real risk involved with allowing malware to use private
storage? If so would this risk warrant that I should take one of the
folowing measures ?:

A) Completely disallow private storage to processes of what the
   uid of the process is the same as the uid of the executable owner.
B) Completely disallow private storage to any process with an executable
   owner other than root.
C) Change the current design so that a user can take incident response
   actions that deletes all private storage in any way linked to that user.
D) Change the current design so that a user can take incident response
   actions that deletes all private storage linked to both the user and a
   specific binary path.

In my view all these measures would diminish the simplicity of the design,
thus I am very hesitant to introduce any of these measures, especialy the
IR measures, without being sure if the fact that malware can in any way
abuse availability of private storage in a risk full manner.


T.I.A.

Rob