Lines Matching +full:system +full:- +full:on +full:- +full:module

17 about Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel Summit.
18 SELinux is an implementation of flexible and fine-grained
31 operations on kernel objects and a set of opaque security fields in
35 migrating the Linux capabilities code into such a module.
40 individuals, including Greg Kroah-Hartman and James Morris, to develop a
44 of the framework and the example capabilities security module provided
52 on supporting access control modules, although future development is
57 module, with the system defaulting to the traditional superuser logic.
58 This capabilities module is discussed further in
59 `LSM Capabilities Module <#cap>`__.
65 general :c:func:`security()` system call to support new system calls
66 for security-aware applications.
78 net_device <net_device>`. For System V IPC security information,
92 collection of substructures that group related hooks based on the kernel
93 object (e.g. task, inode, file, sk_buff, etc) as well as some top-level
94 hook function pointers for system operations. This structure is likely
97 per-hook documentation in the header file. The hook calls can also be
99 "security_ops->".
101 Linus mentioned per-process security hooks in his original remarks as a
103 start from the perspective of per-process hooks, then the base framework
110 hooks, but a security module is free to implement per-process hooks
112 process' security field and then invoking these per-process hooks from
114 module.
117 provided by a dummy security module that provides traditional superuser
119 ``security/security.c``) is provided to allow a security module to set
122 security_ops to the dummy module hooks. This mechanism is used to set
123 the primary security module, which is responsible for making the final
127 modules with the primary security module. It defines
133 after performing some sanity checking. A security module can call these
135 details of how this stacking is handled are deferred to the module,
138 manner, LSM again defers the problem of composition to the module.
140 Although the LSM hooks are organized into substructures based on kernel
157 LSM Capabilities Module
161 logic into an optional security module stored in the file
164 using the dummy module for traditional superuser logic or any other
165 module that they desire. This change also allows the developers of the
170 move the capability-related fields from the kernel data structures into
175 with the capabilities module without needing to chain multiple security
176 structures on the security field. It also avoids imposing extra overhead
177 on the capabilities module to manage the security fields. However, the
181 At present, the capabilities logic for computing process capabilities on
185 :c:func:`capset()` system calls have been moved into the
186 capabilities module. There are still a few locations in the base kernel
187 where capability-related fields are directly examined or modified, but
188 the current version of the LSM patch does allow a security module to
190 locations would need to be changed if the capability-related fields were
193 capability-related fields:
195 -  ``fs/open.c``::c:func:`sys_access()`
197 -  ``fs/lockd/host.c``::c:func:`nlm_bind_host()`
199 -  ``fs/nfsd/auth.c``::c:func:`nfsd_setuser()`
201 -  ``fs/proc/array.c``::c:func:`task_cap()`