Re: Specifications (the beginning)

security@cssc-inc.com

Hi,

> Philippe Biondi wrote:
> 
>    * 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.
>         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.

Can you specify why this is a job not better done by the modules themselves? 
You are right to assume that lids uses a config file too, which is

(/etc/lids/lids.[cap|conf|pw|net|cap])

It comes with an administration tool that allows to make changes to that files
after entering a password.

I think this is a good solution - for this implementation. I think a lot of
people will not like the idea of having to use a standard mechanism to access
their configuration data, and if theres no good reason to implement such a
mechanism, I think we should leave it away. If people insist on doing their own
checks on who is authorized to reload, maybe with a more fine-grained
authentication idea in mind than we do now, this would propose a serious
drawback...

What do you think?

Florian Voegel
CSSC Inc.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module