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.
> > 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.
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.
* 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.
> > > * We need to place this call to this interface wherever it is needed.
> > > Lots of syscalls, VFS calls, socket calls, capable calls ...
> > > Part of this work should be a way to "prove" that nothing has been
> > > forgotten.
> >
> > Impossible. You end up exporting the entire kernel. Better to add exported
> > things to the interface when a module comes along that needs it.
> No exportation is needed : I'm speaking of a function that is part of the
> kernel itself, that will be the hook at these many places in the kernel,
> and that will call appropriate functions of a security policy module for
> it to make the decision. This module would have registered itself before,
> in its init function, with a security_module_register() function, which is
> the only to be exported. Am I clearer this time ? (I hope!)
Yes, you're clear. Apparently I was not. My claim is that it is impossible to
prove that nothing has been forgotten. In fact, I argue that it is not even
desirable to hook everything conceivable. Instead, we should hook only what is
necessary to support modules that are actually contenders to use the LSM. If no
one is going to use some particular hook, then we should leave it out until such
time as someone makes a REALLY strong case to add it.
> > > * We need a mechanism to recognize a process to assign to it its AC data
> > > from the global set of AC data.
> >
> > Hook exec() and fork(), and let the module decide whether the newborn is
> > something that needs policies applied to it. The "recognition" is itself a
> > policy that should be delegated to the modules.
>
> Yes, but what will the recognition rely on ? Path names ? device/inode
> numbers ? fingerprints ?
> - fingerprints can't identify changing files (log files, etc.)
> - pathnames are easily fooled and do not target precisely an object
> - device/inode numbers identify very well an object but happen to
> evolve through time (log file rotated, etc.)
>
> I think that, even with its drawback, the third is the more secure, and
> the one that make most sense. And it happens to work not so bad.
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.
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 : Sat Apr 14 2001 - 16:00:31 PDT