Lines Matching refs:security
23 (*) A note on security.
314 CacheFiles is implemented to deal properly with the LSM security features of
319 security context that is not appropriate for accessing the cache - either
324 The way CacheFiles works is to temporarily change the security context (fsuid,
325 fsgid and actor security label) that the process acts as - without changing the
326 security context of the process when it the target of an operation performed by
332 (1) Finds the security label attached to the root cache directory and uses
333 that as the security label with which it will create files. By default,
338 (2) Finds the security label of the process which issued the bind request
343 and asks LSM to supply a security ID as which it should act given the
348 SELinux transitions the daemon's security ID to the module's security ID
358 The module's security ID gives it permission to create, move and remove files
363 The daemon's security ID gives it only a very restricted set of permissions: it
409 CacheFiles makes use of the split security in the task_struct. It allocates
414 bypassing security and calling inode ops directly. Therefore the VFS and LSM
416 circumstances the caching code is running in the security context of whatever
419 Furthermore, should CacheFiles create a file or directory, the security
420 parameters with that object is created (UID, GID, security label) would be
425 What is required is to temporarily override the security of the process that
427 security data as that affects the process as an object, not just as a subject.
431 So CacheFiles makes use of a logical split in the security between the
432 objective security (task->real_cred) and the subjective security (task->cred).
433 The objective security holds the intrinsic security properties of a process and
438 The subjective security holds the active security properties of a process, and
444 for CacheFiles to run in a context of a specific security label, or to create
445 files and directories with another security label.