On Friday 18 July 2003 11:37, Omen Wild wrote: > 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. Only if your reference is not also corrupted. If the reference IS corrupted then it would appear that fsck WAS altered, even if it was not. Or in the case of "init=/bin/sh" sh would have to be checked. Now a compiled in reference (containing say: sh, fsck, mount, umount, tar, mkfs.xxx and mkfs, cat, ls, mv, rm, ... everything in initrd? and must not forget shared libraries) would likely be safe. But you would then not be able to include the kernel itself (recursion again...), though you would be able to include modules. It would also preclude updates to these items without also rebuilding the kernel too. > > 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? Can - It all depends on what the corruption is. I believe it does when the file map is longer than the file length. The truncation causes the mtime to be changed. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Jul 21 2003 - 05:47:31 PDT