On Sat, Sep 06, 2003 at 12:05:23PM +0200, Ivan Popov wrote:
> On Fri, 5 Sep 2003, Jan Harkes wrote:
> > the only recourse for user B would be to
> > directly modify the container files in the venus cache directory. If he
> > modifies those the files will not be marked as 'dirty' unless user B
> > actually changes bits around in RVM (which will probably lead to a
> > crash if he forgets to link the faked CMLs correctly).
> 
> If a naughty B compiles his/her own venus (or donwloads from a suitable
> script-kiddie site) then this operation will be easy, won't it?

Yeah, at some point there is little that you can do if the target
machine is completely untrusted. It could even have a keyboard
sniffer/screen grabber installed.

But some steps could be taken to improve some areas. One idea is to keep
containerfiles in an encrypted form as long as possible. When a user
revokes his Coda token we could purge the keys necessary to decrypt the
files. If the active/open files in the venus cache are then stored in a
ram-only fs, then no sensitive data should ever have to hit the disk as
far as Coda is concerned. Ofcourse that still doesn't prevent the user
application from writing out temp files or getting swapped out.

> ... soon we'll get script-kiddies trying to hack Coda sites ...

Not really a script-kiddie, but we've already had a DoS exploit :)

http://www.securityfocus.com/archive/1/328478/2003-07-06/2003-07-12/0

Jan