On Sat, 14 Apr 2001, Crispin Cowan wrote:
> Philippe Biondi wrote:
>
> > I just misinterpreted the name of the list. I dislike the presence of the
> > word "module" in it :)
>
> "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. 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.
> > > A much more dicy question is the interface between security modules that
> > > expect AC metadata to be stored in the file system, and file systems that
> > > support extended attributes (e.g. can store an access control list associated
> > > with a file). We don't want the security module interface to only work with
> > > exotic file systems, but we also don't want the security module interface to
> > > preclude using the security-enhancing features of exotic file systems.
> > That is the point : where is stored a rule like "httpd can't read the
> > logs" when the computer is off ?
>
> You got it; that's the question. The answer is is (drumroll please) "Delegate to
> the modules" :-) I.e. each module has to come up with its own solution. There
> are two basic kinds of answers:
>
> * 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)
> 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.
> 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.
> 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.
> * 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.
Can these fs work without patching the VFS layer ?
Anyway, I think we can't go further without having agreed which approach
we'll have to follow :
May the semantic carried by the hook stay the same, and the question asked
will be like :
"Can 'current' exec <syscall> with <parameters>"
May the semantic be enriched with :
"Can 'current' do <type-of-action> with <object(s)>"
(as it is already done. For example :
static int open_port(struct inode * inode, struct file * filp)
{
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
}
We don't ask wether current can open /dev/(mem|kmem|port) but we add a
semantic layer, aliasing this to the need to have CAP_SYS_RAWIO. The
information is richer.)
The first solution seems more powerful at first sight but will become too
heavy to manage and to use because it is raw information that we try to
transmit, IMHO.
--
Philippe Biondi
Systems administrator
Webmotion Inc.
http://www.webmotion.com
mailto:philippe.biondiat_private
Fax. (613) 260-9545
_______________________________________________
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:26:28 PDT