From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:49362 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752853AbeBSPSU (ORCPT ); Mon, 19 Feb 2018 10:18:20 -0500 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1JFGkYK097854 for ; Mon, 19 Feb 2018 10:18:19 -0500 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2g80r199am-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Feb 2018 10:18:18 -0500 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Feb 2018 15:18:16 -0000 From: Mimi Zohar To: linux-integrity@vger.kernel.org Cc: linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, Mimi Zohar Subject: [PATCH v1 0/2] ima: untrusted filesystems Date: Mon, 19 Feb 2018 10:18:01 -0500 Message-Id: <1519053483-18396-1-git-send-email-zohar@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Based on the mailing list discussions, it is clear that separating the non-init unpriviliged, mounted untrusted filesystem from setuid unprivileged or privileged mounted untrusted filesystems patches was confusing. I've combined the patches, commenting the code with an explanation for the differentiation. Instad of expliciting modifying the IMA policy to fail file signature verfication for the setuid unprivileged or privileged mounted untrusted filesystems cases, this patch set defines a builtin IMA policy named "untrusted-fs". No other IMA policy changes are required. Mimi Changelog v1: - Merged the unprivileged and privileged patches. - Dropped IMA fsname support. - Introduced a new IMA builtin policy named "untrusted_fs". - Replaced fs_type flag with sb->s_iflags flag. Mimi Zohar (2): ima: fail signature verification on untrusted filesystems fuse: define the filesystem as untrusted Documentation/admin-guide/kernel-parameters.txt | 6 +++++- fs/fuse/inode.c | 1 + include/linux/fs.h | 1 + security/integrity/ima/ima_appraise.c | 16 +++++++++++++++- security/integrity/ima/ima_policy.c | 5 +++++ security/integrity/integrity.h | 1 + 6 files changed, 28 insertions(+), 2 deletions(-) -- 2.7.5 From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.vnet.ibm.com (Mimi Zohar) Date: Mon, 19 Feb 2018 10:18:01 -0500 Subject: [PATCH v1 0/2] ima: untrusted filesystems Message-ID: <1519053483-18396-1-git-send-email-zohar@linux.vnet.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org Based on the mailing list discussions, it is clear that separating the non-init unpriviliged, mounted untrusted filesystem from setuid unprivileged or privileged mounted untrusted filesystems patches was confusing. I've combined the patches, commenting the code with an explanation for the differentiation. Instad of expliciting modifying the IMA policy to fail file signature verfication for the setuid unprivileged or privileged mounted untrusted filesystems cases, this patch set defines a builtin IMA policy named "untrusted-fs". No other IMA policy changes are required. Mimi Changelog v1: - Merged the unprivileged and privileged patches. - Dropped IMA fsname support. - Introduced a new IMA builtin policy named "untrusted_fs". - Replaced fs_type flag with sb->s_iflags flag. Mimi Zohar (2): ima: fail signature verification on untrusted filesystems fuse: define the filesystem as untrusted Documentation/admin-guide/kernel-parameters.txt | 6 +++++- fs/fuse/inode.c | 1 + include/linux/fs.h | 1 + security/integrity/ima/ima_appraise.c | 16 +++++++++++++++- security/integrity/ima/ima_policy.c | 5 +++++ security/integrity/integrity.h | 1 + 6 files changed, 28 insertions(+), 2 deletions(-) -- 2.7.5 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html