Re: Hooks and stacking

From: John Richard Moser (nigelenki@private)
Date: Wed Mar 30 2005 - 19:03:44 PST


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



John Richard Moser wrote:
> Which version of Linux will first implement stacking in LSM as per Serge
> Hallyn's patches?
> 
> Where is the new documentation?
> 
> 
> As for hooks, a few questions.
> 

A few more.

4.  file_mmap() is only a check; however, to be very unintrusive, I want
to be able to alter vm_flags in do_mmap_pgoff().  Particularly, I want
to be able to supply a mask to AND them with.  The current code looks like:

        error = security_file_mmap(file, prot, flags);
        if (error)
                return error;

To accomplish this task, one of two venues would be taken.  The first,
shown below, adds a new hook in the same place:

        error = security_file_mmap(file, prot, flags);
        if (error)
                return error;
	/* Serge's stacking code should AND together each thing we get
	 * back from each module to produce the most restrictive set
	 */
	vm_flags &= security_file_mmap_vm_flags(file, prot, flags);

The second alters the current hook, requiring all LSMs using the
file_mmap() hook to be rewritten:

	{
		int my_vm_flags = ~0;
	        error = security_file_mmap(file, prot, flags,
		  &my_vm_flags);
	        if (error)
        	        return error;
		/* Serge's stacking code should AND together each
		 *  my_vm_flags
		 */
		vm_flags &= my_vm_flags;
	}

Having one hook is most elegant; breaking an API is least elegant.
Which would be more likely to be genuinely accepted as an LSM hook
modification?

5.  do_brk() also only has a check, but I wish to elegantly control what
may happen here.  I would need a hook that would allow me to supply
something to AND flags with after the following line:

        flags = VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags;

So for example:

        flags = VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags;
	/* stacking should AND together each value and return the
	 * result
	 */
	flags &= security_vm_brk();

I would of course have my module returning (~VM_MAYEXEC) as in PaX.

6.  It looks as if I can modify the vma to handle relocations the same
way PaX does from security_file_mprotect().  That's fine.  Now all I
have to do is figure out htf pip's logic works, mainly where the data
that is set for certain checks comes from.  Relocations aren't magically
MAY_WRITE, even if they come like that by default.

7.  Shared memory mappings seem to always be in VM_WRITE | VM_MAYWRITE,
so they're sane by default at creation time.  Control over mprotect()
has this covered beyond that.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCS2iQhDd4aOud5P8RAjgRAJ4hAimdOzF2Uf/SE9lCeTswHrBU4wCfW64Y
02HLNYKVSp3j5L5RszjuMJQ=
=KMxQ
-----END PGP SIGNATURE-----



This archive was generated by hypermail 2.1.3 : Wed Mar 30 2005 - 19:04:02 PST