On Sat, Apr 14, 2001 at 03:57:15PM -0700, Crispin Cowan wrote: > o Supporting "read a conf file" requires that the module have some way to > read a file from within the kernel, which is actually rather hard. > SubDomain kludges this with a funny ioctl, but it's gross. > o There are also security issues involved in who may cause the conf file > to be read, because the attacker may hack the file and induce a reload. > Thus the security module itself must have control over who may cause a > reload. > o I suggest that we add an explicit feature for LSM modules to read > configuration files. The stimulus to read the file would come from > user-land, but must be viewed as a request, not a commandment. The > request must come with a bunch of authenication data, so that the LSM > module can properly consider the request. > o Adding a single system call for "read your conf file now" would be one > way. The system call could have arguments that specify things like the > secuity identity of the requestor (other than UID, PID, etc.) and > perhaps cryptographic credentials. Eeek! No! The kernel should _not_ be reading _any_ userspace config files. It doesn't solve any "trust" issues of having the kernel read the file vs. a userspace program sending the already parsed data to the kernel module through an ioctl or filesystem handle. If you _really_ want to do that, fine, implement it in your module, but we are not going to put that "functionality" into the generic interface. > * Depend on extended attributes: > o Traditional MAC and ACL systems do this. It requires that the file > system support extended attributes, so you can attach stuff like the > list of security IDs that may access a file to the file. > o LSM must enable the use of extended attributes, but must not require > extended attributes to work. This is because the particular extended > attributes that each file system supports is not standardized, so if we > mandate one, we lock ourselves in to a particular file system, which is > a disaster. > o To achieve this, we need only ensure that whatever funky extended > attribute manipulation functions come with each file system are exported > to the LSM interface. If that is already the case, then we just have to > avoid breaking it. Does anyone know of any filesystems that currently support ACLs (besides NTFS) that the kernel currently handles in a "different" way? I don't think we want to mess with filesystem ACLs in this module, let's leave the filesystem privileges checks in the individual filesystems where it is today. > And the LSM interface should not be making such decisions for LSM modules. We > should make available the information needed to use each of the above features, > and let each module use its own preferred method. Immunix's SubDomain module uses > absolute path names (dentries), and CryptoMark enforces fingerprints. Thus > SubDomain needs access to the dentry of a file, and CryptoMark needs access to the > code space of a file that is about to be exec'd. Other modules may need different > information, and LSM should provide it to them. CryptoMark only needs to be told that a file is about to be exec'd, it handles all of the verification of it on its own (no special code space access needed). With the model that Chris has published, it looks like it currently supports the following security models: - capabilities - SubDomain (actually SubDomain needs some more things that the proposed model doesn't export, I'll work on defining that next week.) - CryptoMark What we are after is what does each of the other individual projects need access to, where do they need access to this, and what information do they need at that time. Many of those (void) functions need to be filled out with some information, and we need to determine what superset fulfills all of the different projects. thanks, greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg _______________________________________________ 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 : Sat Apr 14 2001 - 17:30:25 PDT