lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <85f392a2-7c81-a744-0bd2-ed97fbc7f66e@linux.microsoft.com>
Date:   Thu, 12 Nov 2020 14:02:30 -0800
From:   Tushar Sugandhi <tusharsu@...ux.microsoft.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>, stephen.smalley.work@...il.com,
        casey@...aufler-ca.com, agk@...hat.com, snitzer@...hat.com,
        gmazyland@...il.com, paul@...l-moore.com
Cc:     tyhicks@...ux.microsoft.com, sashal@...nel.org, jmorris@...ei.org,
        nramas@...ux.microsoft.com, linux-integrity@...r.kernel.org,
        selinux@...r.kernel.org, linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, dm-devel@...hat.com
Subject: Re: [PATCH v5 4/7] IMA: add policy to measure critical data



On 2020-11-06 5:43 a.m., Mimi Zohar wrote:
> Hi Tushar,
> 
> On Sun, 2020-11-01 at 14:26 -0800, Tushar Sugandhi wrote:
>> System administrators should be able to choose which kernel subsystems
>> they want to measure the critical data for. To enable that, an IMA policy
>> option to choose specific kernel subsystems is needed. This policy option
>> would constrain the measurement of the critical data to the given kernel
>> subsystems.
> 
> Measuring critical data should not be dependent on the source of the
> critical data.   This patch needs to be split up.  The "data sources"
> should be move to it's own separate patch.  This patch should be
> limited to adding the policy code needed for measuring criticial data.
> Limiting critical data sources should be the last patch in this series.
> 
> thanks,
> 
> Mimi
> 
Thanks Mimi.

Ok. I will split the patches as you suggested.
Patch #1 (this patch) will have the policy code needed for measuring
critical data.
patch #2 Limiting the critical “data_sources”.

*Question 1*
Since you said patch #2 should be the last patch in this series, do you 
mean merging patch #2 with the SeLinux patch? (patch 7/7 of this series)
Or a separate patch before 7/7?

*Question 2*
If I understand it correctly, the following code should be moved from 
this patch to patch #2. Did I miss anything?

  static const match_table_t policy_tokens = {
@@ -957,6 +971,7 @@ static const match_table_t policy_tokens = {
  	{Opt_pcr, "pcr=%s"},
  	{Opt_template, "template=%s"},
  	{Opt_keyrings, "keyrings=%s"},
+	{Opt_data_sources, "data_sources=%s"},
  	{Opt_err, NULL}
  };


+		case Opt_data_sources:
+			ima_log_string(ab, "data_sources",
+				       args[0].from);
+
+			if (entry->data_sources) {
+				result = -EINVAL;
+				break;
+			}
+
+			entry->data_sources = ima_alloc_rule_opt_list(args);
+			if (IS_ERR(entry->data_sources)) {
+				result = PTR_ERR(entry->data_sources);
+				entry->data_sources = NULL;
+				break;
+			}
+
+			entry->flags |= IMA_DATA_SOURCES;
+			break;

+	if (entry->flags & IMA_DATA_SOURCES) {
+		seq_puts(m, "data_sources=");
+		ima_show_rule_opt_list(m, entry->data_sources);
+		seq_puts(m, " ");
+	}
+

~Tushar

>>
>> Add a new IMA policy option - "data_sources:=" to the IMA func
>> CRITICAL_DATA to allow measurement of various kernel subsystems. This
>> policy option would enable the system administrators to limit the
>> measurement to the subsystems listed in "data_sources:=", if the
>> subsystem measures its data by calling ima_measure_critical_data().
>>
>> Limit the measurement to the subsystems that are specified in the IMA
>> policy - CRITICAL_DATA+"data_sources:=". If "data_sources:=" is not
>> provided with the func CRITICAL_DATA, measure the data from all the
>> supported kernel subsystems.
>>
>> Signed-off-by: Tushar Sugandhi <tusharsu@...ux.microsoft.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ