Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1607467imm; Tue, 22 May 2018 06:45:01 -0700 (PDT) X-Google-Smtp-Source: AB8JxZraiS5NPMU11dleXb+w20zPbMKmch+ylRk5A0GUgWDSuKzLqRPHs0At4oyDnpIKAQb3o0+7 X-Received: by 2002:a17:902:8494:: with SMTP id c20-v6mr25063876plo.66.1526996701663; Tue, 22 May 2018 06:45:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526996701; cv=none; d=google.com; s=arc-20160816; b=TjjaML4VbqAn24/ix59PwQ78t0w6xjYiaWp8Gd8etA3paqGcGqzTbkM5iEi9UHkHJh TYGVp6v1tqqI78bfPkBOtDqT5KB8aXGvKZm8Rt1BZ1bNHZXO1xG2rr7dCM18sDkTpDlK TImJVEhxaXHzLXE8+8xEv/Qh/702nU58W7sjBA1v/txU+W3+y9Uoyohjl27NXpIIB6fh ZT+hR2ikmQKNTlCxQNX3ukc0eToqWlmnNXCPtlwtrXup40eYztn2gTKST8ZU4UZI5oc5 LatXpbUAOwR3B9kwK8tXzJ/8b803Ws1B+Yz+hrGf49BycT/zz1PdbjGauFIbnuJ0R+m+ ahvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=FtJtYx2kd5fR9jHTSzvmZlmiBAaEI4X9a6zl5vh+Yho=; b=vIPs0r1vBNMoXvUbn3Vfr5ihDk+XiNa2juPV0kWowh98d/mxDB1JM0N/OcTCx2tkKJ F0dOFdA5e4faTLT7SFte4FFOpBcOSaOlxOzGl1yksD0uALU8Fv6YrDGSUPGPfV46Qc5e zVPPt872vDb6feBCsCIjxm4NhKB0tZ2Tni6148yVNaY2osIoTtTxxjg2qYzBCOZaBvhq DZldl7FFpQTD0LdIR0iRCtpZWCwQ+Zlze/7t6yrnKoWPSO3q2gojBA8X+nH0hMu134lN n6xcnmAwkZAP3KFXiPmPMRZo89Bj/U3792EvRwjqvQPZabEqDs03xkNGS8hylJ013YTe HOgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bh1-v6si15923161plb.481.2018.05.22.06.44.46; Tue, 22 May 2018 06:45:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751369AbeEVNog (ORCPT + 99 others); Tue, 22 May 2018 09:44:36 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:48576 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751199AbeEVNof (ORCPT ); Tue, 22 May 2018 09:44:35 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 24018407049F; Tue, 22 May 2018 13:44:35 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-24.rdu2.redhat.com [10.10.112.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 03FB110E51BF; Tue, 22 May 2018 13:44:28 +0000 (UTC) Date: Tue, 22 May 2018 09:43:46 -0400 From: Richard Guy Briggs To: Stefan Berger Cc: Steve Grubb , Mimi Zohar , containers@lists.linux-foundation.org, Linux-Audit Mailing List , linux-integrity , LKML , paul@paul-moore.com Subject: Re: [PATCH] audit: add containerid support for IMA-audit Message-ID: <20180522134346.b3bm7ndfjjchju3b@madcap2.tricolour.ca> References: <1520257393.10396.291.camel@linux.vnet.ibm.com> <2397631.78oLu0QVqb@x2> <21646a72-e782-e33a-9e75-5cc98b241f36@linux.vnet.ibm.com> <4015765.rtofcNpGHU@x2> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171027 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 22 May 2018 13:44:35 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 22 May 2018 13:44:35 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'rgb@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-05-21 17:57, Stefan Berger wrote: > On 05/21/2018 02:30 PM, Steve Grubb wrote: > > Hello Stefan, > > > > On Monday, May 21, 2018 1:53:04 PM EDT Stefan Berger wrote: > > > On 05/21/2018 12:58 PM, Steve Grubb wrote: > > > > On Thursday, May 17, 2018 10:18:13 AM EDT Stefan Berger wrote: > > > > > > audit_log_container_info() then releasing the local context. This > > > > > > version of the record has additional concerns covered here: > > > > > > https://github.com/linux-audit/audit-kernel/issues/52 > > > > > Following the discussion there and the concern with breaking user space, > > > > > how can we split up the AUDIT_INTEGRITY_RULE that is used in > > > > > ima_audit_measurement() and ima_parse_rule(), without 'breaking user > > > > > space'? > > > > > > > > > > A message produced by ima_parse_rule() looks like this here: > > > > > > > > > > type=INTEGRITY_RULE msg=audit(1526566213.870:305): action="dont_measure" > > > > > fsmagic="0x9fa0" res=1 > > > > Why is action and fsmagic being logged as untrusted strings? Untrusted > > > > strings are used when an unprivileged user can affect the contents of the > > > > field such as creating a file with space or special characters in the > > > > name. > > > > > > > > Also, subject and object information is missing. Who loaded this rule? > > > > > > > > > in contrast to that an INTEGRITY_PCR record type: > > > > > > > > > > type=INTEGRITY_PCR msg=audit(1526566235.193:334): pid=1615 uid=0 auid=0 > > > > > ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > > > > > op="invalid_pcr" cause="open_writers" comm="scp" > > > > > name="/var/log/audit/audit.log" dev="dm-0" ino=1962625 res=1 > > > > Why is op & cause being logged as an untrusted string? This also has > > > > incomplete subject information. > > > It's calling audit_log_string() in both cases: > > > > > > https://elixir.bootlin.com/linux/latest/source/security/integrity/integrity > > > _audit.c#L48 > > I see. Looking things over, I see that it seems like it should do the right > > thing. But the original purpose for this function is here: > > > > https://elixir.bootlin.com/linux/latest/source/kernel/audit.c#L1944 > > > > This is where it is logging an untrusted string and has to decide to encode > > it or just place it in quotes. If it has quotes, that means it's an untrusted > > string but has no control characters in it. I think you want to use > > audit_log_format() for any string that is trustworthy. > > Replacing all occurrences (in IMA) of audit_log_string() with > audit_log_format(). > > > > > > As an aside, I wonder why audit_log_string() is in the API when it is a > > helper to audit_log_untrustedstring() ? Without understanding the rules of > > untrusted strings, it can't be used correctly without re-inventing > > audit_log_untrustedstring() by hand. > > > > > > > > > Should some of the fields from INTEGRITY_PCR also appear in > > > > > INTEGRITY_RULE? If so, which ones? > > > > pid, uid, auid, tty, session, subj, comm, exe, res. <- these are > > > > required to be searchable > > > > > > > > > We could probably refactor the current integrity_audit_message() and > > > > > have ima_parse_rule() call into it to get those fields as well. I > > > > > suppose adding new fields to it wouldn't be considered breaking user > > > > > space? > > > > The audit user space utilities pretty much expects those fields in that > > > > order for any IMA originating events. You can add things like op or > > > > cause before > > > We will call into audit_log_task, which will put the parameters into > > > correct order: > > > > > > auid uid gid ses subj pid comm exe > > I'm telling you what the correct order is. :-) A long time ago, the IMA > > :-) Thanks. Was getting confused. > > > system had audit events with the order I'm mentioning. For example, here's > > one from a log I collected back in 2013: > > > > type=INTEGRITY_PCR msg=audit(1327409021.813:21): pid=1 uid=0 auid=4294967295 > > ses=4294967295 subj=kernel op="add_template_measure" cause="hash_added" > > comm="init" name="01parse-kernel.sh" dev=rootfs ino=5413 res=0 > > > > it was missing "tty" and "exe", but the order is as I mentioned. The > > expectation is that INTEGRITY events maintain this established order across > > all events. > > I am *appending* exe= and tty= now: > > type=INTEGRITY_PCR msg=audit(1526939047.809:305): pid=1609 uid=0 auid=0 > ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > op="invalid_pcr" cause="open_writers" comm="ssh" > name="/var/lib/sss/mc/passwd" dev="dm-0" ino=1962679 res=1 > exe="/usr/bin/ssh" tty=tty2 This isn't necessary since they already covered in the already connected SYSCALL record which duplicates even more information than is already. > ?? Stefan > > > -Steve > > > > > https://elixir.bootlin.com/linux/latest/source/kernel/auditsc.c#L2433 > > > > > > > that. The reason why you can do that is those additional fields are not > > > > required to be searchable by common criteria. > > > > > > > > -Steve - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635