backward compat / access (was Re: Benchmarks)

flavienat_private

Hello,

Andrew Morgan wrote:
> 
> How will you handle backward compatibility?
> 
> Kernel X has 75 function definitions in 'struct check_struct'. Kernel
> X+1 has 76. Doesn't a module that was built for version X break in the
> face of this? Are you going to rely on kernel module versioning to help
> address this issue - namely, refuse to load a mis-matched module?

If the kernel interface changes, then you'd have to recompile the 
module. It's the problem of the maintainer of the module to keep
up with versions. We use kernel versionning just like any other 
module, and that's it.

Note that gcc-specific syntax for labeled elements is pretty handy for 
the developper in this case(*). Most of the time, if nothing has
changed, or if things that have changed are not meaningfull for
his module, he just needs to recompile.

The idea of "a NULL pointer in the struct keeps the default -ie no 
check- function in place" is reasonable I think (may be a flag 
'default when nothing specified is refuse' could be useful, I 
dunno).

The idea of replacing a _big_ structure containing all check_* 
function pointers with a structure of ten/fifteen "capability 
check groups", dividing the structure in smaller elements does 
not make any revolution, but looks fine with me.

Something like :

struct check_struct_fs mymodule_fs_checks = {
	check_fs_open: 	   & mymodule_fs_read,
	check_fs_read:     & mymodule_fs_open,
	check_fs_write:    & mymodule_fs_write,
	...
};

struct check_struct_socket mymodule_socket_checks = {
	check_socket_bind:    & mymodule_socket_bind,
	check_socket_connect: & mymodule_socket_connect,
	...
};

struct check_struct = {
	check_fs:     mymodule_fs_checks,
	check_socket: mymodule_socket_checks,
	...
};

The "access()" thing is an interesting problem too. :)
Is there a way for a process to know if it'll be allowed
to "kill" another process ? The only one that I know of
is : "if (kill(pid, 0) == EPERM)". Has anybody ever wanted
a access_kill (or whatever its name, you get the picture) 
function ? 
What about "bind" then ? The only way to know "will I be 
able to do it" is "do it and see if you get EPERM or not" !

The thing that we are adding here is a generic interface
to allow module developpers to bind directly into the
kernel. We're not trying to add "will I be able to do 
this" syscalls ! 
Not that it wouldn't be usefull (though I don't have
any example in mind right now), but it's IMHO a task 
that is out of the scope of this project.

Flavien.
(*)
http://www.cs.ucsb.edu/Facilities/Software/gcc-info/gcc/Labeled_Elements.html

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