Re: [PATCH v2 1/2] security: Add hook to invalidate inode security labels

On 10/4/2015 12:19 PM, Andreas Gruenbacher wrote: > Add a hook to invalidate an inode's security label when the cached > information becomes invalid. Where is this used? If I need to do the same for Smack or any other module, how would I know that it works right? > > Implement the new hook in

[RFC PATCH v2 1/5] kdbus: add creator credentials to the endpoints

In order to effectively enforce LSM based access controls we need to have more information about the kdbus endpoint creator than the uid/gid currently stored in the kdbus_node_type struct. This patch replaces the uid/gid values with a reference to the node creator's credential struct which serves

[RFC PATCH v2 4/5] selinux: introduce kdbus names into the policy

SELinux treats kdbus service names as objects and therefore needs a mechanism to map service names to security labels. This patch adds support for loading kdbus name/label matches with the security policy. The patch supports service name prefix matching to lessen the burden on the policy

[RFC PATCH v2 3/5] lsm: add support for auditing kdbus service names

The kdbus service names will be recorded using 'service', similar to the existing dbus audit records. Signed-off-by: Paul Moore --- ChangeLog: - v2 * Initial draft --- include/linux/lsm_audit.h |2 ++ security/lsm_audit.c |4 2 files changed, 6

[RFC PATCH v2 5/5] selinux: introduce kdbus access controls

Add the SELinux access control implementation for the new kdbus LSM hooks using the new kdbus object class and the following permissions: [NOTE: permissions below are based on kdbus code from Aug 2015] * kdbus:impersonate Send a different security label to kdbus peers. * kdbus:fakecreds

[PATCH] security: selinux: Use a kmem_cache for allocation struct file_security_struct

The size of struct file_security_struct is 16byte at my setup. But, the real allocation size for per each file_security_struct is 64bytes in my setup that kmalloc min size is 64bytes because ARCH_DMA_MINALIGN is 64. This allocation is called every times at file allocation(alloc_file()). So, the

Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

On Sun, Oct 04, 2015 at 06:57:42PM +, Fuchs, Andreas wrote: > Hi Jarkko, > > thanks for the clearification... > > However, I'd recommend against doing so. > > Furthermore, if there is a resource-manager running in userspace, > applications only get virtual handles and TPM might be empty >

RE: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

Hi Jarkko, /dev/tpm0 is single-open only. So if root wants to do anything there, you'd have to stop the tss-daemon first. Or do you see "keyctl magic" only happening in initrd ? I have to admit that I have no experience with the 1.2 trusted key features. Never used them. Is there software

Re: [PATCH v4 1/2] create SMAF module

Hi Benjamin, [auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore] config: s390-allmodconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x

Re: [PATCH v4 0/2] RFC: Secure Memory Allocation Framework

On 10/05/2015 03:11 AM, Benjamin Gaignard wrote: version 4 changes: - rebased on kernel 4.3-rc3 - fix missing EXPORT_SYMBOL for smaf_create_handle() version 3 changes: - Remove ioctl for allocator selection instead provide the name of the targeted allocator with allocation request.

Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

I don't mean to be impolite but could line up your replies properly and avoid top-posting. I'd recommend 72 chars per line. Thanks. On Mon, Oct 05, 2015 at 12:20:47PM +, Fuchs, Andreas wrote: > That's why I propose to give the context-save-blob into the kernel. It > does not require any

[PATCH v4 0/2] RFC: Secure Memory Allocation Framework

version 4 changes: - rebased on kernel 4.3-rc3 - fix missing EXPORT_SYMBOL for smaf_create_handle() version 3 changes: - Remove ioctl for allocator selection instead provide the name of the targeted allocator with allocation request. Selecting allocator from userland isn't the prefered

[PATCH v4 1/2] create SMAF module

Secure Memory Allocation Framework goal is to be able to allocate memory that can be securing. There is so much ways to allocate and securing memory that SMAF doesn't do it by itself but need help of additional modules. To be sure to use the correct allocation method SMAF implement deferred

[PATCH v4 2/2] SMAF: add CMA allocator

SMAF CMA allocator implement helpers functions to allow SMAF to allocate contiguous memory. match() each if at least one of the attached devices have coherent_dma_mask set to DMA_BIT_MASK(32). For allocation it use dma_alloc_attrs() with DMA_ATTR_WRITE_COMBINE and not dma_alloc_writecombine to

Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

On Mon, Oct 05, 2015 at 09:00:48AM +, Fuchs, Andreas wrote: > Hi Jarkko, > > /dev/tpm0 is single-open only. So if root wants to do anything there, > you'd have to stop the tss-daemon first. > Or do you see "keyctl magic" only happening in initrd ? > > I have to admit that I have no

RE: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

That's why I propose to give the context-save-blob into the kernel. It does not require any TPM2_Load of the key-chain or TPM2_CreatePrimary prior to key usage. BTW, in the current TSS2-model context-save-blobs are the preferred way for "moving/copying" loaded objects between two applications

[PATCH]: Smack: pipefs fix in smack_d_instantiate

This fix writes the task label when smack_d_instantiate is called, before the label of the superblock was written on the pipe's inode. Signed-off-by: Roman Kubiak --- security/smack/smack_lsm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH v4 2/2] SMAF: add CMA allocator

Hi Benjamin, [auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please ignore] reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >>

[RFC PATCH] SMAF: smaf_cma can be static

Signed-off-by: Fengguang Wu --- smaf-cma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/smaf/smaf-cma.c b/drivers/smaf/smaf-cma.c index ab38717..9fbd9b7 100644 --- a/drivers/smaf/smaf-cma.c +++ b/drivers/smaf/smaf-cma.c @@ -175,7 +175,7

RE: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

> > I was just pointing out, that the proposed patch will not fit in with > > the current approach in TSS2.0, before this user-facing kernel API is > > set in stone and _corrected_ new syscalls need to be added later. > > Why you would want new system calls? Do you know how hard it is to get >

RE: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

I'm having trouble following the arguments here. Can someone summarize the two (or more) different approaches being proposed? Will Arthur Intel Corporation Server Security Firmware 803-216-2101 -Original Message- From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com] Sent:

RE: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

> > Regarding the in-kernel "minimal resource manager": AFAIK there is > > already a tpm-mutex inside the kernel. We could use that mutex and > > then have the algorithm: > > > > [SNIP] > > I don't care about one purpose hacks. Second, I don't care about pseudo > code (at least not for "too big

Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

On Mon, Oct 05, 2015 at 01:36:18PM +, Fuchs, Andreas wrote: > > It's still unnecessary functionality and increases the kernel image size > > and every hack requires maintenance. It would probably end up needing > > compilation flag as there exists efforts like: > > > >