On Tue, 2006-06-27 at 12:29 -0500, Kris Wilson wrote: > We are trying to finalize our list of syscalls to test and have the > following questions: > > Are the following available to regular users or administrators only: > > add_key > request_key > keyctl
Regular users. SELinux checks for the key operations only went upstream recently, post 2.6.17. > kexec_load > rtas These appear to be restricted to superuser via capability checks. > Can someone point us to documentation which might help determine security > relevance > for the following: > > inotify_add_watch This one would have the usual file permission checks applied (search to the directories, read to the file) for the file being watched. No check on the inotify instance itself here. > inotify_init This creates an inotify object. Question is how it would end up being labeled and subsequently controlled if it can be shared between processes. Seems a bit suspect - not sure why genfs is being used for inotifyfs in the policy; I'd have expected it to use fs_use_task, similar to pipes. Then the inodes would inherit the level of the creating task, and the checks on execve and/or local IPC would control sharing. > inotify_rm_watch This doesn't appear to perform any checks. > debug_setcontext Not familiar. > ioprio_get > ioprio_set A security hook was recently added for ioprio_set. No checking (DAC or MAC) is currently applied on ioprio_get. But it can be used to get the ioprio of another task, so it seems suspect. > migrate_pages A security hook was recently added to this one. -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
