Re: Making forward progress

sarnoldat_private

As a response to jmjones's recent question asking what is left, I felt
it might be useful to look at Stephen's todo list from a little while
back, and see just how much progress has been made since then. :)

On Thu, Aug 02, 2001 at 12:05:02PM -0400, Stephen Smalley wrote:
> 1) Move all hook calls after the DAC logic.

Hmm. This appears to have been mostly done, as long as we allow some
fudging on the definition of 'DAC'. :)

> 2) Complete the capability module, as this is
> an important selling point for LSM.  This means
> moving the capability-specific logic from
> access, capget, and capset into the module,
> possibly moving the capability bits from
> linux_binprm and task_struct (and perhaps
> some of the network-related structures) into
> the security blobs, and fixing any remaining
> kernel references to the capability bits.

Well, our capabilities module still looks an awful lot like the
built-in capabilities support already in the kernel -- at least, it
doesn't do anything with the security blobs. Whether or not recoding to
support using the security blobs is a good idea or not, I just don't
know. Stephen, now that you have had a week's experience or so with the
second LSM-based release of SELinux, what do you think of the current
capabilities module?

> 3) Continue to define and implement 
> additional networking hooks based on our experiences 
> with using the current networking hooks for our various modules.

I have no idea about progress on this front -- I don't know much about
the Linux networking code. I know I would appreciate it if someone could
assure me that the information available in the networking hooks allows
for dropping packets, mangling packets?, modifying the security state of
processes, based on rules including task information, interface,
addresses used, etc...

> 4) Consider hooks for miscellaneous operations like
> nfsservctl, quotactl, bdflush, swapon, swapoff, stime/settimeofday,
> syslog, prctl (some of these had hooks defined in the SGI
> patch).

Hmm. We've got nfsservctl, quotactl, bdflush, swapon, swapoff, syslog,
and prctl covered. There isn't anything for the stime/settimeofday, not
that I could quickly see anyway. (There is a capable() hook in
do_sys_settimeofday, however...) Are there other miscellaneous
operations that still need hooks? :)

> 5) As previously recommended by Chris Wright:
> a) Review all current hook calls for placement, error handling,
> and parameters.  With respect to parameters, be sure that
> we aren't passing user space pointers or at least explicitly
> mark such parameters.

Good idea.

> b) Review the alloc/free hook calls for leaks.

Good idea.

> c) Place or remove any unused hooks.

Are there any hooks that people would like to nominate for removal? :)

> d) See if we can make the file system hooks consistent in their
> usage of struct vfsmount vs. struct super_block.

Hmmm. There appear to be five uses of struct super_block and five uses
of struct vfsmount. I don't know enough about the individual hooks to
tell if this is fine, or indicitive of trouble.

Not on this list, but also important -- higher level documentation. The
SELinux team put together some decent enough high level docs; perhaps
they should be reviewed again with the light of trying to provide more
background/history/context for the project? (It might be the docs are
fine enough as they are. :)

Comments?

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