Re: [PATCH v12 0/5] overlayfs override_creds=off
On 7/30/2019 10:28 AM, Mark Salyzyn wrote: > Patch series: Please add linux-security-mod...@vger.kernel.org to the CC for all changes affecting handling of security xattrs. > > overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh > Add flags option to get xattr method paired to __vfs_getxattr > overlayfs: handle XATTR_NOSECURITY flag for get xattr method > overlayfs: internal getxattr operations without sepolicy checking > overlayfs: override_creds=off option bypass creator_cred > > The first four patches address fundamental security issues that should > be solved regardless of the override_creds=off feature. > on them). > > The fifth adds the feature depends on these other fixes. > > By default, all access to the upper, lower and work directories is the > recorded mounter's MAC and DAC credentials. The incoming accesses are > checked against the caller's credentials. > > If the principles of least privilege are applied for sepolicy, the > mounter's credentials might not overlap the credentials of the caller's > when accessing the overlayfs filesystem. For example, a file that a > lower DAC privileged caller can execute, is MAC denied to the > generally higher DAC privileged mounter, to prevent an attack vector. > > We add the option to turn off override_creds in the mount options; all > subsequent operations after mount on the filesystem will be only the > caller's credentials. The module boolean parameter and mount option > override_creds is also added as a presence check for this "feature", > existence of /sys/module/overlay/parameters/overlay_creds > > Signed-off-by: Mark Salyzyn > Cc: Miklos Szeredi > Cc: Jonathan Corbet > Cc: Vivek Goyal > Cc: Eric W. Biederman > Cc: Amir Goldstein > Cc: Randy Dunlap > Cc: Stephen Smalley > Cc: linux-unio...@vger.kernel.org > Cc: linux-doc@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > > --- > v12: > - Restore squished out patch 2 and 3 in the series, > then change algorithm to add flags argument. > Per-thread flag is a large security surface. > > v11: > - Squish out v10 introduced patch 2 and 3 in the series, > then and use per-thread flag instead for nesting. > - Switch name to ovl_do_vds_getxattr for __vds_getxattr wrapper. > - Add sb argument to ovl_revert_creds to match future work. > > v10: > - Return NULL on CAP_DAC_READ_SEARCH > - Add __get xattr method to solve sepolicy logging issue > - Drop unnecessary sys_admin sepolicy checking for administrative > driver internal xattr functions. > > v6: > - Drop CONFIG_OVERLAY_FS_OVERRIDE_CREDS. > - Do better with the documentation, drop rationalizations. > - pr_warn message adjusted to report consequences. > > v5: > - beefed up the caveats in the Documentation > - Is dependent on > "overlayfs: check CAP_DAC_READ_SEARCH before issuing exportfs_decode_fh" > "overlayfs: check CAP_MKNOD before issuing vfs_whiteout" > - Added prwarn when override_creds=off > > v4: > - spelling and grammar errors in text > > v3: > - Change name from caller_credentials / creator_credentials to the > boolean override_creds. > - Changed from creator to mounter credentials. > - Updated and fortified the documentation. > - Added CONFIG_OVERLAY_FS_OVERRIDE_CREDS > > v2: > - Forward port changed attr to stat, resulting in a build error. > - altered commit message. >
Re: [RFC 0/7] Introduce TEE based Trusted Keys support
On 6/13/2019 3:30 AM, Sumit Garg wrote: > Add support for TEE based trusted keys where TEE provides the functionality > to seal and unseal trusted keys using hardware unique key. Also, this is > an alternative in case platform doesn't possess a TPM device. > > This series also adds some TEE features like: Please expand the acronym TEE on first use. That will help people who don't work with it on a daily basis understand what you're going on about. > > Patch #1, #2 enables support for registered kernel shared memory with TEE. > > Patch #3 enables support for private kernel login method required for > cases like trusted keys where we don't wan't user-space to directly access > TEE service to retrieve trusted key contents. > > Rest of the patches from #4 to #7 adds support for TEE based trusted keys. > > This patch-set has been tested with OP-TEE based pseudo TA which can be > found here [1]. > > Looking forward to your valuable feedback/suggestions. > > [1] https://github.com/OP-TEE/optee_os/pull/3082 > > Sumit Garg (7): > tee: optee: allow kernel pages to register as shm > tee: enable support to register kernel memory > tee: add private login method for kernel clients > KEYS: trusted: Introduce TEE based Trusted Keys > KEYS: encrypted: Allow TEE based trusted master keys > doc: keys: Document usage of TEE based Trusted Keys > MAINTAINERS: Add entry for TEE based Trusted Keys > > Documentation/security/keys/tee-trusted.rst | 93 + > MAINTAINERS | 9 + > drivers/tee/optee/call.c | 7 + > drivers/tee/tee_core.c | 6 + > drivers/tee/tee_shm.c| 16 +- > include/keys/tee_trusted.h | 84 > include/keys/trusted-type.h | 1 + > include/linux/tee_drv.h | 1 + > include/uapi/linux/tee.h | 2 + > security/keys/Kconfig| 3 + > security/keys/Makefile | 3 + > security/keys/encrypted-keys/masterkey_trusted.c | 10 +- > security/keys/tee_trusted.c | 506 > +++ > 13 files changed, 737 insertions(+), 4 deletions(-) > create mode 100644 Documentation/security/keys/tee-trusted.rst > create mode 100644 include/keys/tee_trusted.h > create mode 100644 security/keys/tee_trusted.c >
Re: [PATCH security-next v5 00/30] LSM: Explict ordering
On 11/14/2018 1:04 PM, Casey Schaufler wrote: > On 10/24/2018 1:12 PM, Kees Cook wrote: >> On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler >> wrote: >>> On 10/23/2018 12:05 PM, Casey Schaufler wrote: >>>> On 10/23/2018 11:50 AM, Kees Cook wrote: >>>> >>>>> Did you poke around at my combined series? >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing >>>> I hope to do that on the plane later today. >>> I had a chance to poke at the combined series and it >>> all seems to work as advertised. >> /me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;) >> >> -Kees >> > Now that we have next-general updated I'm porting these forward. I have ported Kees' set forward to 4.20-rc2: https://github.com/cschaufler/lsm-stacking.git#after-kees-4.20-rc2 There's one bug fix in ordered_lsm_parse() but otherwise just mechanical. The infrastructure blob management required for TOMOYO, Landlock and SARA is available: https://github.com/cschaufler/lsm-stacking.git#blobs-4.20-rc2 There's nothing new here, although I had to make a few changes to account for Kees' changes in the preceding patches. I will post the patches shortly. The full stacking changes based on this are still in the works. Netfilter has added a whole new use of secmarks and I'm working to make the individual patches smaller for easier review.
Re: [PATCH security-next v5 00/30] LSM: Explict ordering
On 10/24/2018 1:12 PM, Kees Cook wrote: > On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler > wrote: >> On 10/23/2018 12:05 PM, Casey Schaufler wrote: >>> On 10/23/2018 11:50 AM, Kees Cook wrote: >>> >>>> Did you poke around at my combined series? >>>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing >>> I hope to do that on the plane later today. >> I had a chance to poke at the combined series and it >> all seems to work as advertised. > /me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;) > > -Kees > Now that we have next-general updated I'm porting these forward.
Re: [PATCH security-next v5 00/30] LSM: Explict ordering
On 10/23/2018 12:05 PM, Casey Schaufler wrote: > On 10/23/2018 11:50 AM, Kees Cook wrote: > >> Did you poke around at my combined series? >> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing > I hope to do that on the plane later today. I had a chance to poke at the combined series and it all seems to work as advertised.
Re: [PATCH security-next v5 00/30] LSM: Explict ordering
On 10/23/2018 11:50 AM, Kees Cook wrote: > On Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler > wrote: >> On 10/12/2018 12:01 PM, Kees Cook wrote: >>> On Friday, October 12, 2018 3:19 AM, John Johansen >>> wrote: >>>> It isn't perfect but it manages consistency across distros as best as >>>> can be achieved atm. >>> Yeah, this is why I'm okay with the current series: it provides as >>> consistent a view as possible, but leaves room for future improvements >>> (like adding "+" or "!" or "all" or whatever). >>> >>> I'm curious to see what SELinux folks think of v5, though. I *think* I >>> addressed all the concerns there, even Paul's "I want my distro >>> default to not have extreme stacking" case too. >>> >>> -Kees >> Looks like I should go on vacation more often. :) >> >> I am generally opposed to fancy specification languages. >> I support the explicit lsm= list specification because you >> don't have to know any context to create a boot line that >> will work, and be as close to what you've specified as possible >> for the kernel configuration. One need look no further than >> the mechanisms for setting POSIX ACLs for an example of >> how to ensure a feature isn't used. >> >> Had we the foresight to make security= take a list of >> modules when Yama was added we might have avoided some of >> this brouhaha, but there was no reason to expect that stacking >> was ever going to happen back then. > This sounds like an "Ack" for you? :) I'll harass everyone in person > in a couple days. Acked-by: Casey Schaufler > Did you poke around at my combined series? > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing I hope to do that on the plane later today. > -Kees
Re: [PATCH security-next v5 00/30] LSM: Explict ordering
On 10/12/2018 12:01 PM, Kees Cook wrote: > On Friday, October 12, 2018 3:19 AM, John Johansen > wrote: >> It isn't perfect but it manages consistency across distros as best as >> can be achieved atm. > Yeah, this is why I'm okay with the current series: it provides as > consistent a view as possible, but leaves room for future improvements > (like adding "+" or "!" or "all" or whatever). > > I'm curious to see what SELinux folks think of v5, though. I *think* I > addressed all the concerns there, even Paul's "I want my distro > default to not have extreme stacking" case too. > > -Kees Looks like I should go on vacation more often. :) I am generally opposed to fancy specification languages. I support the explicit lsm= list specification because you don't have to know any context to create a boot line that will work, and be as close to what you've specified as possible for the kernel configuration. One need look no further than the mechanisms for setting POSIX ACLs for an example of how to ensure a feature isn't used. Had we the foresight to make security= take a list of modules when Yama was added we might have avoided some of this brouhaha, but there was no reason to expect that stacking was ever going to happen back then.
Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
On 9/24/2018 5:18 PM, Kees Cook wrote: > v3: > - add CONFIG_LSM_ENABLE and refactor resulting logic Kees, you can add my Reviewed-by:Casey Schaufler for this entire patch set. Thank you for taking this on, it's a significant and important chunk of the LSM infrastructure update. > ... > Breakdown of patches: > > Infrastructure improvements (no logical changes): > LSM: Correctly announce start of LSM initialization > vmlinux.lds.h: Avoid copy/paste of security_init section > LSM: Rename .security_initcall section to .lsm_info > LSM: Remove initcall tracing > LSM: Convert from initcall to struct lsm_info > vmlinux.lds.h: Move LSM_TABLE into INIT_DATA > LSM: Convert security_initcall() into DEFINE_LSM() > LSM: Record LSM name in struct lsm_info > LSM: Provide init debugging infrastructure > LSM: Don't ignore initialization failures > > Split "integrity" out into "ordered initialization" (no logical changes): > LSM: Introduce LSM_FLAG_LEGACY_MAJOR > LSM: Provide separate ordered initialization > > Provide centralized LSM enable/disable infrastructure: > LoadPin: Rename "enable" to "enforce" > LSM: Plumb visibility into optional "enabled" state > LSM: Lift LSM selection out of individual LSMs > LSM: Prepare for arbitrary LSM enabling > LSM: Introduce CONFIG_LSM_ENABLE > LSM: Introduce lsm.enable= and lsm.disable= > LSM: Prepare for reorganizing "security=" logic > LSM: Refactor "security=" in terms of enable/disable > > Provide centralized LSM ordering infrastructure: > LSM: Build ordered list of ordered LSMs for init > LSM: Introduce CONFIG_LSM_ORDER > LSM: Introduce "lsm.order=" for boottime ordering > > Move minor LSMs into ordered LSM initialization: > LoadPin: Initialize as ordered LSM > Yama: Initialize as ordered LSM > LSM: Introduce enum lsm_order > capability: Initialize as LSM_ORDER_FIRST > > Move major LSMs into ordered LSM initialization: > LSM: Separate idea of "major" LSM from "exclusive" LSM > LSM: Add all exclusive LSMs to ordered initialization > > -Kees > > .../admin-guide/kernel-parameters.txt | 20 + > arch/arc/kernel/vmlinux.lds.S | 1 - > arch/arm/kernel/vmlinux-xip.lds.S | 1 - > arch/arm64/kernel/vmlinux.lds.S | 1 - > arch/h8300/kernel/vmlinux.lds.S | 1 - > arch/microblaze/kernel/vmlinux.lds.S | 2 - > arch/powerpc/kernel/vmlinux.lds.S | 2 - > arch/um/include/asm/common.lds.S | 2 - > arch/xtensa/kernel/vmlinux.lds.S | 1 - > include/asm-generic/vmlinux.lds.h | 25 +- > include/linux/init.h | 2 - > include/linux/lsm_hooks.h | 43 ++- > include/linux/module.h| 1 - > security/Kconfig | 61 ++- > security/apparmor/lsm.c | 16 +- > security/commoncap.c | 8 +- > security/integrity/iint.c | 5 +- > security/loadpin/Kconfig | 4 +- > security/loadpin/loadpin.c| 28 +- > security/security.c | 351 +++--- > security/selinux/hooks.c | 16 +- > security/smack/smack_lsm.c| 8 +- > security/tomoyo/tomoyo.c | 7 +- > security/yama/yama_lsm.c | 7 +- > 24 files changed, 438 insertions(+), 175 deletions(-) >
Re: [PATCH 13/17] doc: ReSTify Smack.txt
On 5/13/2017 4:51 AM, Kees Cook wrote:
> Adjusts for ReST markup and moves under LSM admin guide.
>
> Cc: Casey Schaufler
> Signed-off-by: Kees Cook
Acked-by: Casey Schaufler
Thank you.
> ---
> .../Smack.txt => admin-guide/LSM/Smack.rst}| 273
> ++---
> Documentation/admin-guide/LSM/index.rst| 1 +
> Documentation/security/00-INDEX| 2 -
> MAINTAINERS| 2 +-
> 4 files changed, 191 insertions(+), 87 deletions(-)
> rename Documentation/{security/Smack.txt => admin-guide/LSM/Smack.rst} (85%)
>
> diff --git a/Documentation/security/Smack.txt
> b/Documentation/admin-guide/LSM/Smack.rst
> similarity index 85%
> rename from Documentation/security/Smack.txt
> rename to Documentation/admin-guide/LSM/Smack.rst
> index 945cc633d883..6a5826a13aea 100644
> --- a/Documentation/security/Smack.txt
> +++ b/Documentation/admin-guide/LSM/Smack.rst
> @@ -1,3 +1,6 @@
> +=
> +Smack
> +=
>
>
> "Good for you, you've decided to clean the elevator!"
> @@ -14,6 +17,7 @@ available to determine which is best suited to the problem
> at hand.
>
> Smack consists of three major components:
> +
> - The kernel
> - Basic utilities, which are helpful but not required
> - Configuration data
> @@ -39,16 +43,24 @@ The current git repository for Smack user space is:
> This should make and install on most modern distributions.
> There are five commands included in smackutil:
>
> -chsmack- display or set Smack extended attribute values
> -smackctl - load the Smack access rules
> -smackaccess - report if a process with one label has access
> - to an object with another
> +chsmack:
> + display or set Smack extended attribute values
> +
> +smackctl:
> + load the Smack access rules
> +
> +smackaccess:
> + report if a process with one label has access
> + to an object with another
>
> These two commands are obsolete with the introduction of
> the smackfs/load2 and smackfs/cipso2 interfaces.
>
> -smackload - properly formats data for writing to smackfs/load
> -smackcipso - properly formats data for writing to smackfs/cipso
> +smackload:
> + properly formats data for writing to smackfs/load
> +
> +smackcipso:
> + properly formats data for writing to smackfs/cipso
>
> In keeping with the intent of Smack, configuration data is
> minimal and not strictly required. The most important
> @@ -56,15 +68,15 @@ configuration step is mounting the smackfs pseudo
> filesystem.
> If smackutil is installed the startup script will take care
> of this, but it can be manually as well.
>
> -Add this line to /etc/fstab:
> +Add this line to ``/etc/fstab``::
>
> smackfs /sys/fs/smackfs smackfs defaults 0 0
>
> -The /sys/fs/smackfs directory is created by the kernel.
> +The ``/sys/fs/smackfs`` directory is created by the kernel.
>
> Smack uses extended attributes (xattrs) to store labels on filesystem
> objects. The attributes are stored in the extended attribute security
> -name space. A process must have CAP_MAC_ADMIN to change any of these
> +name space. A process must have ``CAP_MAC_ADMIN`` to change any of these
> attributes.
>
> The extended attributes that Smack uses are:
> @@ -73,14 +85,17 @@ SMACK64
> Used to make access control decisions. In almost all cases
> the label given to a new filesystem object will be the label
> of the process that created it.
> +
> SMACK64EXEC
> The Smack label of a process that execs a program file with
> this attribute set will run with this attribute's value.
> +
> SMACK64MMAP
> Don't allow the file to be mmapped by a process whose Smack
> label does not allow all of the access permitted to a process
> with the label contained in this attribute. This is a very
> specific use case for shared libraries.
> +
> SMACK64TRANSMUTE
> Can only have the value "TRUE". If this attribute is present
> on a directory when an object is created in the directory and
> @@ -89,27 +104,29 @@ SMACK64TRANSMUTE
> gets the label of the directory instead of the label of the
> creating process. If the object being created is a directory
> the SMACK64TRANSMUTE attribute is set as well.
> +
> SMACK64IPIN
> This attribute is only available on file descriptors for sockets.
> Use the Smack label in this attribute for access control
> decisions on packets being delivered to this socket.
> +
> SMACK64IPOUT
> This attribute is only available on file
Re: [PATCH 06/17] doc: security: minor cleanups to build kernel-doc
On 5/13/2017 4:51 AM, Kees Cook wrote:
> These fixes were needed to parse lsm_hooks.h kernel-doc. More work is
> needed, but this is the first step.
>
> Cc: Casey Schaufler
> Signed-off-by: Kees Cook
Acked_by: Casey Schaufler
Tell me more about the additional work that's needed.
> ---
> include/linux/lsm_hooks.h | 25 -
> 1 file changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 080f34e66017..a1eeaf603d2f 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -29,6 +29,8 @@
> #include
>
> /**
> + * union security_list_options - Linux Security Module hook function list
> + *
> * Security hooks for program execution operations.
> *
> * @bprm_set_creds:
> @@ -193,8 +195,8 @@
> * @value will be set to the allocated attribute value.
> * @len will be set to the length of the value.
> * Returns 0 if @name and @value have been successfully set,
> - * -EOPNOTSUPP if no security attribute is needed, or
> - * -ENOMEM on memory allocation failure.
> + * -EOPNOTSUPP if no security attribute is needed, or
> + * -ENOMEM on memory allocation failure.
> * @inode_create:
> * Check permission to create a regular file.
> * @dir contains inode structure of the parent of the new file.
> @@ -510,8 +512,7 @@
> * process @tsk. Note that this hook is sometimes called from interrupt.
> * Note that the fown_struct, @fown, is never outside the context of a
> * struct file, so the file structure (and associated security information)
> - * can always be obtained:
> - * container_of(fown, struct file, f_owner)
> + * can always be obtained: container_of(fown, struct file, f_owner)
> * @tsk contains the structure of task receiving signal.
> * @fown contains the file owner information.
> * @sig is the signal that will be sent. When 0, kernel sends SIGIO.
> @@ -521,7 +522,7 @@
> * to receive an open file descriptor via socket IPC.
> * @file contains the file structure being received.
> * Return 0 if permission is granted.
> - * @file_open
> + * @file_open:
> * Save open-time permission checking state for later use upon
> * file_permission, and recheck access if anything has changed
> * since inode_permission.
> @@ -1143,7 +1144,7 @@
> * @sma contains the semaphore structure. May be NULL.
> * @cmd contains the operation to be performed.
> * Return 0 if permission is granted.
> - * @sem_semop
> + * @sem_semop:
> * Check permissions before performing operations on members of the
> * semaphore set @sma. If the @alter flag is nonzero, the semaphore set
> * may be modified.
> @@ -1153,20 +1154,20 @@
> * @alter contains the flag indicating whether changes are to be made.
> * Return 0 if permission is granted.
> *
> - * @binder_set_context_mgr
> + * @binder_set_context_mgr:
> * Check whether @mgr is allowed to be the binder context manager.
> * @mgr contains the task_struct for the task being registered.
> * Return 0 if permission is granted.
> - * @binder_transaction
> + * @binder_transaction:
> * Check whether @from is allowed to invoke a binder transaction call
> * to @to.
> * @from contains the task_struct for the sending task.
> * @to contains the task_struct for the receiving task.
> - * @binder_transfer_binder
> + * @binder_transfer_binder:
> * Check whether @from is allowed to transfer a binder reference to @to.
> * @from contains the task_struct for the sending task.
> * @to contains the task_struct for the receiving task.
> - * @binder_transfer_file
> + * @binder_transfer_file:
> * Check whether @from is allowed to transfer @file to @to.
> * @from contains the task_struct for the sending task.
> * @file contains the struct file being transferred.
> @@ -1214,7 +1215,7 @@
> * @cred contains the credentials to use.
> * @ns contains the user namespace we want the capability in
> * @cap contains the capability .
> - * @audit: Whether to write an audit message or not
> + * @audit contains whether to write an audit message or not
> * Return 0 if the capability is granted for @tsk.
> * @syslog:
> * Check permission before accessing the kernel message ring or changing
> @@ -1336,9 +1337,7 @@
> * @inode we wish to get the security context of.
> * @ctx is a pointer in which to place the allocated security context.
> * @ctxlen points to the place to put the length of @ctx.
> - * This is the main security structure.
> */
> -
> union security_list_options {
> int (*binder_set_context_mgr)(struct task_struct *mgr);
> int (*binder_transaction)(struct task_struct *from,
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
