| Message ID | 20190618230551.7475-1-casey@schaufler-ca.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | LSM: Module stacking for AppArmor | expand |
On Tue, Jun 18, 2019 at 04:05:26PM -0700, Casey Schaufler wrote: > Patches 0001-0003 complete the process of moving managment > of security blobs that might be shared from the individual > modules to the infrastructure. I think these are happy stand-alone patches and should just go into the common LSM tree for v5.3.
On Tue, Jun 18, 2019 at 04:05:26PM -0700, Casey Schaufler wrote: > Patches 0004-0014 replace system use of a "secid" with > a structure "lsmblob" containing information from the > security modules to be held and reused later. At this > point lsmblob contains an array of u32 secids, one "slot" > for each of the security modules compiled into the > kernel that used secids. A "slot" is allocated when > a security module registers a hook for one of the interfaces > that uses a secid or a security context. The infrastructure > is changed to use the slot number to pass the correct > secid to or from the security module hooks. I found 14/25 in your git tree. Very satisfying to see all the scaffolding vanish for process_measurement() :) I like this progression in 4-14; I find it much much easier to review. My only complaint is the variable names. I think I'd prefer "blob" over "le" or "l", which are both contain very little information about what they are.
On 6/18/2019 9:34 PM, Kees Cook wrote: > On Tue, Jun 18, 2019 at 04:05:26PM -0700, Casey Schaufler wrote: >> Patches 0001-0003 complete the process of moving managment >> of security blobs that might be shared from the individual >> modules to the infrastructure. > I think these are happy stand-alone patches and should just go into the > common LSM tree for v5.3. They don't have a user without the rest of the patchset, but they do make the internals more consistent. James' call.
On 6/18/2019 10:21 PM, Kees Cook wrote: > On Tue, Jun 18, 2019 at 04:05:26PM -0700, Casey Schaufler wrote: >> Patches 0004-0014 replace system use of a "secid" with >> a structure "lsmblob" containing information from the >> security modules to be held and reused later. At this >> point lsmblob contains an array of u32 secids, one "slot" >> for each of the security modules compiled into the >> kernel that used secids. A "slot" is allocated when >> a security module registers a hook for one of the interfaces >> that uses a secid or a security context. The infrastructure >> is changed to use the slot number to pass the correct >> secid to or from the security module hooks. > I found 14/25 in your git tree. Very satisfying to see all the > scaffolding vanish for process_measurement() :) > > I like this progression in 4-14; I find it much much easier to review. > My only complaint is the variable names. I think I'd prefer "blob" over > "le" or "l", which are both contain very little information about what > they are. I know what they are! OK, I get it. Using "blob" would make it more obvious. It's an relatively easy change, so I'll incorporate it going forward.
On Tue, 18 Jun 2019, Kees Cook wrote: > On Tue, Jun 18, 2019 at 04:05:26PM -0700, Casey Schaufler wrote: > > Patches 0001-0003 complete the process of moving managment > > of security blobs that might be shared from the individual > > modules to the infrastructure. > > I think these are happy stand-alone patches and should just go into the > common LSM tree for v5.3. We extended stacking support in March to allow Landlock and SARA to be merged and have not seen anything from them since. Is there any point in adding more of the same for v5.3 before the current AppArmor stacking changes are fully ready? This seems to carry risk but no concrete benefit for the release.
On Thu, Jun 20, 2019 at 06:08:03AM +1000, James Morris wrote: > We extended stacking support in March to allow Landlock and SARA to be > merged and have not seen anything from them since. Salvatore and Mickaël, have you had a chance to look at the stacking changes? I'd love to see work progress on your LSMs now that the stacking prerequisites have landed. Thanks!
On June 20, 2019 7:33:25 PM GMT+02:00, Kees Cook <keescook@chromium.org> wrote: > On Thu, Jun 20, 2019 at 06:08:03AM +1000, James Morris wrote: > > We extended stacking support in March to allow Landlock and SARA to > be > > merged and have not seen anything from them since. > > Salvatore and Mickaël, have you had a chance to look at the stacking > changes? I'd love to see work progress on your LSMs now that the > stacking prerequisites have landed. > > Thanks! Yes, I successfully updated Landlock as a stackable LSM. I also worked on removing some code (and related features, for now) to get smaller patches for the next round, and I tried to get rid of the VFS modifications. I still need to update the tests, rebase a last time and review everything before sending a new patch set, hopefully next week. Mickaël
This patchset provides the changes required for the AppArmor security module to stack safely with any other. Patches 0001-0003 complete the process of moving managment of security blobs that might be shared from the individual modules to the infrastructure. Patches 0004-0014 replace system use of a "secid" with a structure "lsmblob" containing information from the security modules to be held and reused later. At this point lsmblob contains an array of u32 secids, one "slot" for each of the security modules compiled into the kernel that used secids. A "slot" is allocated when a security module registers a hook for one of the interfaces that uses a secid or a security context. The infrastructure is changed to use the slot number to pass the correct secid to or from the security module hooks. It is important that the lsmblob be a fixed size entity that does not have to be allocated. Several of the places where it is used would have performance and/or locking issues with dynamic allocation. Patch 0015 provides a mechanism for a process to identify which security module's hooks should be used when displaying or converting a security context string. A new interface /proc/.../attr/display contains the name of the security module to show. Reading from this file will present the name of the module, while writing to it will set the value. Only names of active security modules are accepted. Internally, the name is translated to the appropriate "slot" number for the module which is then stored in the task security blob. Patch 0016 Starts the process of changing how a security context is represented. Since it is possible for a security context to have been generated by more than one security module it is now necessary to note which module created a security context so that the correct "release" hook can be called. There are several places where the module that created a security context cannot be inferred. This is achieved by introducing a "lsmcontext" structure which contains the context string, its length and the "slot" number of the security module that created it. The security_release_secctx() interface is changed, replacing the (string,len) pointer pair with a lsmcontext pointer. Patches 0012-0021 convert the security interfaces from (string,len) pointer pairs to a lsmcontext pointer. The slot number identifying the creating module is added by the infrastructure. Where the security context is stored for extended periods the data type is changed. Patch 0022 provides a simple way for a security module to know its "slot" number. The security_add_hooks() initialization function returns the slot number, and the security module need but stash the value for later use, as is required by the Netlabel subsystem. The Netlabel code is converted to save lsmblob structures instead of secids in Patch 0023. Patch 0024 allows for an error return of -ENOPROTOOPT to be ignored while processing security_getprocattr(). Finally, with all interference on the AppArmor hooks removed, Patch 0025 removes the exclusive bit from them. The Ubuntu project is using an earlier version of this patchset in their distribution to enable stacking for containers. Performance measurements to date have the change within the "noise". Better benchmarks are in the works. https://github.com/cschaufler/lsm-stacking.git#stack-5.2-v4-apparmor Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> --- drivers/android/binder.c | 24 +- fs/kernfs/dir.c | 5 +- fs/kernfs/inode.c | 35 ++- fs/kernfs/kernfs-internal.h | 3 +- fs/nfs/nfs4proc.c | 22 +- fs/nfsd/nfs4xdr.c | 20 +- fs/proc/base.c | 1 + include/linux/cred.h | 3 +- include/linux/lsm_hooks.h | 8 +- include/linux/security.h | 163 ++++++++++--- include/net/af_unix.h | 2 +- include/net/netlabel.h | 8 +- include/net/scm.h | 14 +- kernel/audit.c | 34 +-- kernel/audit.h | 9 +- kernel/auditfilter.c | 6 +- kernel/auditsc.c | 77 +++---- kernel/cred.c | 12 +- net/ipv4/cipso_ipv4.c | 6 +- net/ipv4/ip_sockglue.c | 12 +- net/netfilter/nf_conntrack_netlink.c | 20 +- net/netfilter/nf_conntrack_standalone.c | 11 +- net/netfilter/nfnetlink_queue.c | 26 ++- net/netfilter/nft_meta.c | 13 +- net/netfilter/xt_SECMARK.c | 6 +- net/netlabel/netlabel_kapi.c | 6 +- net/netlabel/netlabel_unlabeled.c | 95 ++++---- net/netlabel/netlabel_unlabeled.h | 2 +- net/netlabel/netlabel_user.c | 13 +- net/netlabel/netlabel_user.h | 6 +- net/unix/af_unix.c | 6 +- security/apparmor/include/net.h | 6 +- security/apparmor/lsm.c | 48 ++-- security/integrity/ima/ima.h | 14 +- security/integrity/ima/ima_api.c | 9 +- security/integrity/ima/ima_appraise.c | 6 +- security/integrity/ima/ima_main.c | 38 ++-- security/integrity/ima/ima_policy.c | 19 +- security/security.c | 392 ++++++++++++++++++++++++++++---- security/selinux/hooks.c | 164 ++++++------- security/selinux/include/objsec.h | 18 ++ security/selinux/include/security.h | 1 + security/selinux/netlabel.c | 25 +- security/selinux/ss/services.c | 7 +- security/smack/smack.h | 19 ++ security/smack/smack_lsm.c | 154 ++++++------- security/smack/smack_netfilter.c | 8 +- security/smack/smackfs.c | 10 +- 48 files changed, 1010 insertions(+), 596 deletions(-)