>>> To reinterate: In the context of the Linux
> kernel capabilities are the mechanism by
> which a process is allowed to violate
> system policy. Some of the system policy,
> including certain ioctl() calls and
> some resource controls, is not security
> policy.
>> We're talking at length about a hypithetical
> (I know I spelled that wrong. sorry)
> implementation of a policy that hasn't been
> defined. I challenge y'all to propose an
> authority policy. Who knows, maybe it will
> make scence in the context of capabilities.
I will try to lay down a set of system calls and how I believe these
could be put into 'user' ambient linux capabilities that when explicitly
made non inherited before exec could produce a usefull result for POLA
based
system design on top of it. Althouh hopelessly incomplete, it should
give you some context as to what such capabilities would bring.
I believe people on the cap-talk list will be able to point out a few issues
with the inventarisation below, but as a way to show the general direction
to you and the LSM people it should be reasonably OK.
What I would propose for 'user' Linux capabilities would be something
along the lines of the below description. It's just a quick
inventarisation, so don't take it to be complete, it most likely is not.
I'll try to focus purely on communication and file handle related system
calls as those are the most relevant.
First there are a set of system calls that by their nature imply ambient
authority, and thus could be govened
by user level Linux Caps rather streight forward:
CAP_USER_AMBIENT_NET_IN: socketcall::bind
CAP_USER_AMBIENT_NET_OUT: socketcall::connect
CAP_USER_AMBIENT_IPC_POSIX: mq_open,mq_unlink
CAP_USER_AMBIENT_IPC_IV: ipc
CAP_USER_AMBIENT_FS: access,chdir,chmod,creat,execve,fstatfs,
fstatfs64,ftime,inotify_add_watch,
lchown,lchown32,lgetxattr,link,listxattr,
llistxattr,lremovexattr,lsetxattr,lstat,
lstat64,mkdir,mknod,oldlstat,oldfstat,
oldstat,open,readlink,removexattr,rename,
rmdir,setxattr,stat,stat64,statfs,
statfs64,symlink,truncate,truncate64,unlink
The new 'at' family holds a few calls that in most usage imply ambient
authority, however if and only if the path supplied with these cals is
'relative' and 'down' from the given file descriptor than the directory
file descriptor can be seen as delegatable tokens of authority in the same
way that regular file handles can.
CAP_USER_AMBIENT_FS || PATH_IS_RELATIVE_DOWN(fdX,pathX)
faccessat,fstatat64,futimesat,mkdirat,
mknodat,openat,readlinkat,unlinkat,
renameat,linkat,symlinkat
With delegation of directories, DAC could be used to effectively simulate
faccets for entries in delegated directories, however this would be mostly
limited to first delegation. DAC should with POLA only be used with all r,
all w and all x bits synchonized. Further setting of unset bits hould be
allowed,that is the new mode should be a subset of the old value, and DAC
based delegation controlls should not be allowed. (If you are wondering
what about regular DAC security issues, you should only delegate
directories
that have an unguessable name and are contained in a 0700 DAC set directory
themselves).
CAP_USER_AMBIENT_FS || MODE_IS_SUBSET_NONRESTRICT_DELEGATION(mode,oldmode)
fchmod
CAP_USER_AMBIENT_FS ||
(MODE_IS_SUBSET_NONRESTRICT_DELEGATION(mode,oldmode) &&
PATH_IS_RELATIVE(fd,path) )
fchmodat
For practical purposes, the loading of libraries can probably not be
restricted for most processes. That is, restriction can mostly only be
done by disallowing untrusted library paths. This one I am realy
uncomfortable with, its definetly not POLA, but we practically might not
be able to do it
differently.
CAP_USER_AMBIENT_FS || (CAP_USER_AMBIENT_USELIB && TRUSTED_LIB_PATH(path))
uselib