On Sun, Feb 24, 2013 at 02:23:49PM -0500, [email protected] wrote: > On Sun, Feb 24, 2013 at 01:42:18PM -0500, Patrick R McDonald wrote: > > Lastly, given the list of the above, are these issues fixable within > > Tahoe-LAFS under the current scenario (compromised device) or are these > > something where we need to deploy a secure OS to prevent the scenario? > > What's a "secure OS"? > > You wouldn't put a node on the open Internet with a guest account or > some other means to allow anyone to log in. You wouldn't provide a means > for anyone to run arbitrary commands on your node without first gaining > authorized access. > > So what do you mean by "secure OS"?
Reviewing what I wrote, "secure OS" was agreeably a poor choice of words. My apologies. Let see if the below better explains my thought process and where I am looking to go. As a redundant array of clouds becomes more and more a reality, thanks to the efforts of Least Authority Enterprises and others, Simon's thread popped a thought in my head. How do we protect ourselves against attacks from service providers who have full root access on one or more of our storage nodes? Please don't take this thread as an insinuation that any specific service provider would do something malicious. Instead, it is a thought exercise to get me to understand better what Tahoe-LAFS can and can't protect against and what protections I as the sysadmin of my storage grid might need to implement. To help prevent this thread from be coming a runaway train, let me articulate the particular threat models which interest me. The first is the curious, but non-malicious sysadmin for a service provider. This is the person who has no ill intent towards me, just simply wishes to explore the contents of my grid as a way to pass the time. The second is local/federal law enforcement who are looking for incriminating evidence. Does this provide a better frame around the information I seek? Thanks, Patrick
pgpEoirlWAJJC.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
