Re: Is this the kind of thing ... ?
I don't think your ideas can make it into the core of the Hurd.
However they could perhaps be implemented with add-on
servers/libraries.
simeonscott@iname.com writes:
> EG, if you want to store a script file, which you want to be
> able to run, but don't want others to be able to read, you
> can. To run it, you pipe it through the de-cryption algorithm
> to the interpreter/compiler of your choice.
(Oops, I wrote the following before noticing you have written
more about this problem below.)
Assume I am compiling a secret C program consisting of hello.c
and hello.h. I could pipe the decrypted hello.c to the compiler
(preprocessor actually), but when it sees an #include directive,
it will try to open a hello.h, and how am I going to get another
pipe there?
The Hurd allows connecting a decrypting translator to hello.h so
that when the compiler opens the file, the translator provides it
with decrypted text. But in that case, other users could open
the file too and get plaintext from the translator. So the
translator needs to control who can read from it, and this brings
us back to the read-permission bits you wanted to get rid of.
Also, think of /etc/passwd... even though the passwords are
encrypted, they can be broken and now we have /etc/shadow which
most users can't read. Encryption is nice, but permission bits
don't hurt either.
> The encryption tools should provide the ability to store a
> miniature 'file system' entirely in a file (optionally with
> embedded 'free-space' to disguise the acutal size of the
> file(s) ).
I believe the easiest way to implement that in the current Hurd
would be to add encryption support in libstore. Then you could
have an ext2fs filesystem in an encrypted file.
> System files, by being readable to anyone, benefit from the
> same random 'potential scrutiny' as log files (see above).
I don't think this scrutiny will be effective in practice. I
don't read the log files on my own system (unless something
strange happens), and on a machine with dozens of users it would
be much more work to keep up with all the data.
> The second one is outwardly easiest to deal with. Offload the
> work to the user's own PC/local terminal/anonymously redirected
> login which is difficult to trace, where another physically
> remote system does the number crunching.
Ah. So the Hurd would be run on the server only?
> For this to work, the accounting records maintained in the
> 'file- system' encrypted file need to be randomly distributed,
> and of random length.
Some Dallas microcontrollers have an encrypted address bus; the
same could be done with file offsets. I don't think that'd be
good for access times, though.
> The physical integrity of the system could be ensured eg by use of
> CCTV (web) cameras - physical redundancy of the system-box itself
> (ie two of them) would cater for physical repairs. UPS (battery
> backup) systems would cater for power-outages.
This sounds expensive.
> Different levels of log-file detail to which a user subscribes
> could carry different weightings in a vote, perhaps these
> weightings would accumulate with time, and deplete gradually
> when unsubscribed.
How are you going to check that the user really reads the data he
receives?
Reply to: