Philippe Biondi wrote: > On Sat, 14 Apr 2001, Crispin Cowan wrote: > > "module" is the *most* important word in the list name. There's lots & lots of > > generic security discussion forums, and even lots of linux security discussion > > forums. I'm trying to chase awasy all of the discussion about the merrits of one > > security model over another, and concentrate on the LSM features needed to support > > a diverse set of security modules. > > I agree if module means modular and not LKM. Yes, it means LKM. We are not talking about turning Linux into a microkernel here, just adding sufficient functionality to the LKM interface to enable security LKMs to exist (which I've been denoting LSM for "Linux Security Module", hence the list name). > Wanting to make a modular > implementation is important and means that we can get security policies > out of the kernel, in LKMs. Wanting to make a LKM is nonsense, IMHO. I don't really understand what you're saying here. You seem to be contradicting yourself, but mostly I'm just confused. > > * Put it in a .conf file: > > o Janus and SubDomain do this. Subdomain by default reads that kind of > > information from the files found in /etc/subdomain.d/* . Janus does > > something similar, but I'm not up on the particulars. I suspect LIDS > > does this, but I don't know. > LIDS does it too (/etc/lids) Makes sense. > > 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. > It's quite easy !? with things like filp_open() (which are already > exported). Maybe I missed something. As Greg helpfully reminded me, there are problems asking the kernel to read ASCII from user space files: * kernel blocking on a disk I/O * disk read errors * parsing errors * etc. So it's best to have a program push the file into the kernel, rather than let the kernel read it direct from a file. Then the program can fail gracefully, rather than the kernel taking the hit when something goes wrong. > > 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. > If the config file is agreed to be the best solution for storing rules, > reading a config file must be a service provided, as lots of models will > need it. It is not "aggreed to be the best solution". It is agreed to be a commonly-used approach which needs to be supported. It is important that the LSM interface should *not* impose opinions as to what is the best solution, where ever possible. > Can these fs work without patching the VFS layer ? By definition, yes: ext2 supports a form of extended attributes. You access those attributes with the chattr and lsatter commands. http://www.securityfocus.com/focus/linux/articles/ext2attr.html However, some other extended attributes projects apparently require patching the VFS layer http://lwn.net/2000/1026/a/extended-attributes.php3 I agree with Greg: we don't want to get into a can of worms in the VFS layer. The trick is to figure out how to allow modules to use extended attributes without getting entangled. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org _______________________________________________ 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 : Sun Apr 15 2001 - 00:20:11 PDT