[cap-talk] Designation linux kernel patch concept
Rob Meijer
capibara at xs4all.nl
Fri Nov 30 04:19:20 EST 2007
I have been giving some thougth about the posibilities of a designation
patch for the linux kernel, to be used by AppArmor (or other linux
security modules) that want to distinguish designated Fd's.
Before I start trying to implement it, I thougth I would run it
by you guys to see if I am on the right track here.
My linux kernel development experience is very small, so I could be
overlooking some important stuff here.
Please let me know what you think.
Rob
--------------------------------------------------------------------
This short text describes a possible patch to the linux kernel that
would allow linux security modules to use file descriptors and directory
file descriptors as tokens of authority, and to distinguish between
situations were access is requested directly and situations where a
delegated Fd is used as a source of delegated authority.
The linux syscall API basically has 3 sets of system calls where
both a path based and an Fd based version exists, and from recent
discussion on the cap-talk and AppArmor mailinglist it is asumed
that an LSM may wish to implement aditional sets.
We further need to recognise that some path based system calls have
an equivalent in multiple of these sets (fchown/fchownat,fchmod/fchmodat,
fstat/fstatat), so the patch should also permit
1) Single file Fd
The folowing system calls have a path based equivalent, and designate
a single file Fd:
* fchown
* fchmod
* fstat
* fstatfs
* ftruncate
* fchdir
* flistxattr
* fgetxattr
* fsetxatt
* fremovexattr
Next to this, it is likely that an LSM that wants to distinguish between
delegated and direct authority may want to implement its own:
* fexecve
2) Single directory Fd
The folowing system calls have a path based equivalent, and designate
a single directory Fd:
* fchownat
* fchmodat
* fstatat
* unlinkat
* symlinkat
* readlinkat
* openat
* mknodat
* mkdirat
3) Dual directory Fd
The folowing system calls have a path based equivalent, and designate
two distinct directory Fd's:
* linkat
* renameat
4) Additional Fdset
Although no system calls exist that take an fdset as argument and that
have an equivalent that doesn't do this, the problem of accidentaly
passed Fd's across exec will be likely to make LSM authors want to
implement a system
call like:
int safe_execve(const char *filename, char *const argv[],
char *const envp[],fd_set *keepfds);
Here 'keepfds' could be the inverse of the normaly used close on exec
flag.
In addition to, or instead of the abouve safe_execve, an LSM may want to
implement a file Fd based version of this call:
int fexecve(int filedes, char *const argv[],
char *const envp[],fd_set *keepfds);
Instead of safe_execve, an LSM may want to implement an 'at' version
of this call:
int fexecve(int dirfd,const char *pathname, char *const argv[],
char *const envp[],fd_set *keepfds);
>From the abouve we may conclude that with two Fd's and an fd_set all forms
of Fd designation may be described. If we add an integer value to these, we
would end up with the folowing structure that could optionaly
(CONF_DESIGNATION) be added to the task structure:
struct fd_designation {
int designation_type;
int fd1;
int fd2;
fd_set *fset;
struct semaphore sem;
}
We shall define the folowing values for designation_type:
0 : no designation (or fdset only).
1 : fd1=file Fd
2 : fd2=dir Fd
3 : fd1=old dirfd, fd2=newdirfd
The semaphore should make sure that multiple threads of the same task
would not mess up the designation of active thread system calls form this
task.
Now we could define two functions, that would would optionaly
(CONF_DESIGNATION) be used in all of the system calls defined abouve:
void fd_designate_setup(int des_type,int f1,int f2,fd_set *fset);
void fd_designate_clear(int des_type,int f1,int f2,fd_set *fset);
This way, during the defined 21 system calls, the fd_designation structure
within the task structure would be set to the proper values, that could
than where appropriate, and any LSM needing this information should be able
to acquire it, without any added hooks for the LSM framework.
More information about the cap-talk
mailing list