-----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