|
|
 |
 |
 |
 |
 |
 |
|
|
|
From: Perry and Lorae Merritt (plmerritt, hypermall dot net) Date: 2001.09.28 - 06.22 MDT
X-Mailer: Microsoft Outlook Express 5.50.4522.1200 For ADC security, can't we just validate that the UID asking about a file or trying to modify a file has permission to the file? Essentially we'd just tie into the OS/file system security that already exists (UID/GID). ----- Original Message ----- From: "Jay Miller" <jnmiller, cryptofreak dot org> To: <antera, cryptofreak dot org> Sent: Thursday, September 27, 2001 9:28 PM Subject: Re: Meeting thoughts and some other stuff. > - Words by Perry and Lorae Merritt <plmerritt, hypermall dot net> [010927 05:19]: > > Don't start with me? I never planned to stop with you. > > Careful - I'll tell my girlfriend to stop talking to you! (I bought her > a laptop.. what did YOU buy her? :) > > > During the meeting you can tell me again(?) how you plan on moving the data > > from the restore operation through the ADML to the fileystem. Are you > > thinking you're going to send it through the portal/ioclt interface? If so, > > how are you going to get it from the restore that is doing file writes? > > Pipes, I suppose. Instead of writing to a normal file descriptor, we > write to stdin and parse the incoming stream for the raw data. We might > also be able to do some verification on file metadata to make sure the > two copies (one of which should be of zero-size) are of one another. > Anyway, once we know what the raw data is (we don't really need the > metadata), we cram it through the portal to the kernel and do standard > write() calls. > > Sounds pretty clean..? > > > It seems to me that if we don't expose our internal mechanism for figuring > > out who's doing the open and subsequent writes, the opportunity for someone > > wanting to break our system should be fairly narrow. In fact, whats to stop > > them from writting their own ADC and doing whatever they want as it is? > > Security through of obscurity? Perry, you should know better than to > propose a scheme like that to me! > > (http://www.loktechnology.com/encryption.html) > > The nice thing about communication with the ADML being kept to only > pieces we write is the ability to have both sides manage the > 'connection'. We are able to negotiate security protocols this way. > Giving messages to our kernel module 'from the top', as it were, makes > it much harder to know who's talking to us. > > Your point about rogue ADC's is actually a very good one to bring up and > keep in mind. The idea that this software setup could be running on > some companies' "master server" implies that hostile actions might be > attempted against our stuff. Access to the ADML, after all, entails > access to anything in the system, including all file data. Any actual > product should probably account for this. Dan, you might wish to think > about this from a sales perspective, too: we're essentially making a back > door into the kernel - something many admins might be hesitant about..? > > Right. > > Now, here's the interesting and (I thought) radical idea we came across > today: no PD. We've mentioned a lot that the ADML layer is just a > flexible way to implement extended attributes (EAs). And we're planning > on never actually deleting the file itself from the FS - just the > metadata. So why not utilize that data structure to store our own data? > > The PDM would still be responsible for managing that stuff, and we might > need to manage some kind of hash or some other quick structure for > searching the EAs (for high UEFs, or whatever..). > > Neat idea? > > I love simplifying things.. > > -- > Jay Miller > > ICQ: 32123421 | YM: ladenedge | http://www.cryptofreak.org > PGP: 0xedc9bb8d | 41a6428c 46abd36b 6b259b68 8a28ca4c edc9bb8c > -- > This is the antera mailing list. To unsubscribe, email > majordomo, cryptofreak dot org with message body `unsubscribe antera'. > Or, for more information, visit http://www.cryptofreak.org/. > -- This is the antera mailing list. To unsubscribe, email majordomo, cryptofreak dot org with message body `unsubscribe antera'. Or, for more information, visit http://www.cryptofreak.org/.
This archive was generated by hypermail 2b30 : 2001.09.29 - 03.00 MDT |
