Hooks, authority, MAC, the future and proposol

lawat_private

Chris Wright wrote:
> the specific changes mentioned above push significant amounts of kernel
> logic into the module.  we already hashed this out on the list and
> decided against it.  we are looking for a minimal impact patch.  we've
> got to get our foot in the door first...(see also cripsin's comments
> regarding our conversation with ted ts'o).
---
        Ted's first comment said sufficient hooks to support access
controls.  There are various access controls to system objects.

Current access controls are done by file mode bits, capabilities and
various uid/gid related checks,  There are also the two "Mandatory
Access Controls", IMMUTABLE, and APPEND_ONLY.  Additionally

There are additional access control types: the POSIX 1e Draft Standard 
MAC and ACL's, Domain enforcement, time-of-day enforcement, type enforcement,
the negative access control policy :all-is-permitted (strongly desired
for embedded systems, etc.

Taken at face value, "access controls" is a fairly broad term.  To 
implement a 'user-arbitrary', general access control policy requires
control over all access decisions.  

Another datum is that there is a need for pre and possibly post 
hooks on most calls.  Some calls only require privilege under
the current Linux security policy.  Privileges (capabilities)
allow a user to selectively violate a particular security policy.
For example, users cannot mount a file system unless it is listed
as being user mountable.  With appropriate privilege, CAP_SYS_ADMIN,
a user can override this restriction.

For any any other place, security is in place to control access
between users.  Any call of this nature needs a pre-hook for POSIX 1e 
style MAC.  MAC can be very restrictive.   All of it's checks must 
be done before you even get to the mode bits on a file because 
data in the inode is part of what MAC protects.  Same with 
inter-process communication, sending signals, looking at another 
process in /proc, etc.

It has been stated before:  we don't want to call 'capable' 
if the file mode is 0777.  In the same way you don't want to return
a DAC failure when the user doesn't have "access" to the data in the
inode needed to perform a DAC check, instead they should get a MAC failure.
Of course, if they have appropriate privilege (appropriate Capability)
then they can override MAC policy and then do the DAC checks, which,
of course, can also be overridden with appropriate privilege.

All of the above can't be done if 'standard linux security' is 
left 'immutable' in the kernel.  

In the case of audit, it wants to know the values of parsed 
arguments and security relevant information.  This requires, 
say, in "open", to record not only DAC pass/fail, but also 
recording the file descriptor of a succcessful call.  File
descriptors are the user space 'handle' the kernel provides to 
the internal file struct.

As a side note that anything said about Audit can also be applied 
to policies that include real-time intrusion detection and 
security enforcement.  If someone is getting many MAC or DAC
failures, a policy could require they be logged off.

Given that audit requires more hooks than are currently
present and making audit a stage II goal, when will that be
addressed?  What is the time frame for allowing audit hooks into
LSM?  In fact, how do people see LSM being in the future?  Once we
get the hooks in do we just "disband" the list or is it seen to be
an ongoing project or what?  Is this sort of a 'one-of' group, where
we go off, design something suitable for all the policies and submit
it, get it accepted that's the end of the group?

We really want LSM to suceed and be useful for our simple
security policy that requires auditing as well as a more beefy
offering that includes MAC.  Someone mentioned Orange Book C2
security -- that requires audit.  Every major unix vendor has at
least something at this level.  B1 security, the next step up,
requires everything that C2 requires + Mandatory Access Control.
The same is true of the modern Common Criteria standard's
CAPP (Controlled Access Protection Profile) and LSPP (Labeled
Security Protection Profile).  Audit is the gateway into the most
basic level of validated or evaluated trusted systems.  

Of the existing hooks, audit will need more information that is sometimes
being passed in.  Externally, at the user interface level, the only
published means of identifying files opened by the user is the file
descriptor.  We need to know the user-land name.  This implies
file descriptors in many cases and, usually, post-kernel parsed
arguments.

So if we are going for stage I.  We'd propose:

1) That the project adopt new prototypes for some of the existing 
security calls to support the argument collection requirements of a 
future audit implementation. Reason: We don't want to force an API change
once the it has been accepted into the kernel.

2) move to authoritative hooks with the standard security moved 
into a module that is compiled in and completely compatible with
the current security (bug for bug, feature for feature).  I know
this topic was discussed last month, but we couldn't give input
at that time.

Comments?
-l

-- 
L A Walsh, law at sgi.com         | Sr Eng, Trust Technology 
01-650-933-5338                   | Core Linux, SGI

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