Quoting Jesse Pollard <jesse@cats-chateau.net> on Fri, Jul 18 11:05: > > Ummmm maybe not... you do have to modify a fileid (since the file is already > being opened anyway). Open the file as usual, then before returning to > the application pass the fileid to the daemon as an already open fileid. > ((I admit - I haven't done this myself)) This would allow the daemon to > implement a queue of fileids to process. I can do that? Pass an open fileid of one process to a process out side the kernel, and then back into the kernel? I've (obviously) never done any programming like that. Which LSM hook catches the file opening? file_permission seems to catch every read/write operation, and inode_permission seems to happen before the file is actually opened. Is there any way to go from the inode passed to inode_permission to the fileid that is causing the security check? > The normal reasons for not doing things in the kernel are: [ snip ] Excellent list, thanks. I'll look it over carefully. > I think you are pushing too far.... How do you know the configuration file > hasn't been messed with? Digital signature. And a way to ensure the public key that we're using to check the signature hasn't been tampered with. I can't reveal how quite yet, we aren't ready to go even semi-public. Building everything into the kernel has the distinct advantage for our system because part of the boot process will be to ensure the kernel hasn't been tampered with. > What are you planning to do about "init=/bin/sh" boot situations where the > system needs repair? (my personal favorite is "init=/sbin/fsck.xxx") That should not be a problem. As fsck gets loaded off of disk, it gets integrity checked. In fact, this would catch the (rare) case when your fsck program itself was corrupted. > What are you going to do when the filesystem is damaged? The normal recovery > is to do a fsck on a RO filesystem, then remount. What if the configuration > file is altered/damaged by the fsck after you read it? I was planning on checking the config file for modification (mtime, inode, device) and re-parsing as necessary. Does a fsck alter the mtime? > What if you can't read it? We have a deeper plan of what to do when the system is corrupt/tampered with. We will be going public in a couple weeks, at which point we will welcome people disassembling our design for flaws. Sorry for being so vague and wish-washy about some of this. It will hopefully become clear after we go public. Omen -- The cause of perfume disappearing is evaporation. Evaporation gets blamed for a lot of things people forget to put the top on.
This archive was generated by hypermail 2b30 : Fri Jul 18 2003 - 09:37:45 PDT