[cap-talk] Persistence: (pseudo)persistent process-private storage: good or bad?

Rob Meijer capibara at xs4all.nl
Mon Jan 21 03:29:56 EST 2008


On Mon, January 21, 2008 03:30, John McCabe-Dansted wrote:
> On Jan 20, 2008 3:56 AM, Rob Meijer <capibara at xs4all.nl> wrote:
>
>> But given the recent discussions about the 'value' of being able to just
>> lose all state by a reboot as an IR measure, I am starting to wonder if
>> this concept would also be subject to the present disagreement, and
>> would
>> thus also be potentialy harmfull.
>
>
> Most systems need persistant state of some form. However it seems to me
> that
> data on traditional UNIX systems have one of three properties
> 1) Disposability: This data can be thrown away. (E.g. /dev/mem, /bin/*)
> 2) Audiablitity:  This data can be audited (text configuration files)
> 3) Safety: This data cannot affect system security on a correctly
> functioning system (e.g. JPEGs)
>
> Rebooting alone does not throw away enough state information, as there may
> be infected binaries. However by reinstalling we can throw away any
> dangerous state information that cannot be audited.
>
> Do your new form of persistent data as storing state information that is
> not
> Disposable, Auditable or Safe?

At the usage level, given that the data is not owned by a user but by
a (user bound) instance of an executable, and the data is 'private' to
this instance of the executable, there would be no disposable or auditable
by the user. It would be auditable at the implementation level by root.
I'm not completely clear about what you mean by 'safety' in this context.

Let me give a short description of how MinorFs should work:

* A user space (fuse) filesystem running as the user 'minorfs' is mounted
  under /home/minorfs/virtual.
* A storage tree is maintained by MinorFs with the folowing structure:
  /home/minorfs/real/<UID>/<EXE-PATH-DIGEST>/<CLAIM-NO>/<FILENAME>
* A process, as an instance of en executable,running with a certain UID,
  can 'claim' a single claim number, and will be presented by a view on
  the real tree, that allows it to access the private data of that claim.


So if I have a program /home/rob/bin/foo (the path has a SHA1 digest
d4abfb686198e5395665562b627dd72b609b6753) running as a user 'rob' with
user id 1004, that runs as a single instance, than this process would
under
/home/minorfs/virtual/ get a 'view' to
/home/minorfs/real/1004/d4abfb686198e5395665562b627dd72b609b6753/0/

The user rob running /bin/ls will get a 'view' to:
/home/minorfs/real/1004/ee8ada67ac2eaf4599758fa2bcb90d4b1a260cf4/0 what is
an entirely different location. Even if a second instance of
/home/rob/bin/foo is started while the first instance is still running,
its view will be to
/home/minorfs/real/1004/d4abfb686198e5395665562b627dd72b609b6753/1/, so
even it would not be able to read write or delete the data of the first
instance.

Do you from this feel that 'safety' would apply, or should I try to
implement a mechanism that would allow the user to 'dispose' of all
private data of specific executable paths?

Rob



More information about the cap-talk mailing list