From owner-soc-status@freebsd.org Tue Jul 10 10:20:25 2018 Return-Path: Delivered-To: soc-status@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08180103C70B for ; Tue, 10 Jul 2018 10:20:25 +0000 (UTC) (envelope-from aniket.ezio41@gmail.com) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CCAD8E9C7 for ; Tue, 10 Jul 2018 10:20:24 +0000 (UTC) (envelope-from aniket.ezio41@gmail.com) Received: by mail-ed1-f49.google.com with SMTP id i20-v6so3154436eds.12 for ; Tue, 10 Jul 2018 03:20:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YL/569Z2JZpX4yvX2ms2qEeohxng4en1OxgEZz8hEOc=; b=NhClaWovedeABJmU8HvCy+5rL024Fi8pLTfzdt2rsrZBSp7TNVAzakoVvuP5zTYjSD Wwa5/KblSEUY+pUpS3ljXhxlU89BDZ3DH2NxzBSJOKZa2ucFJaRr25jz7CIbUfAzsP9O Z0t6oE/Nl97grWU69g7+yAU+xdbatOQIQO46rcCcO9w5xsZurhI8xbRZYymXfTc3/3VB Q6AgHYAMEsej3PD2fuE2GZbiCCLeB4tqba/eh+CY4qPUrVcMfbvh/fwF3eZfc4ROWXtu eeoAoxTxVKsXdboKktjzE+YV9351T1navpCZWaRkZGzEK9KRzGEafW4c75++oOpiskjO 0xxg== X-Gm-Message-State: APt69E0gvRFS1IVv0WtboATgmvca92XRFT1t4sbX6sF3K2mz8fNWsINq ZnNgqljhkuRtnB4BPwwpiyH2dDiO X-Google-Smtp-Source: AAOMgpfYNdHyiTRFtZ7XzoChloYbAKsoocJAGcyLuD1tn85RJj1AOQXbgz7R7LCOzC1M6dOwqEjiaA== X-Received: by 2002:a50:ba6e:: with SMTP id 43-v6mr26699040eds.292.1531218023200; Tue, 10 Jul 2018 03:20:23 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com. [74.125.82.50]) by smtp.gmail.com with ESMTPSA id u9-v6sm4934015edk.16.2018.07.10.03.20.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 03:20:23 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id z13-v6so23733815wma.5 for ; Tue, 10 Jul 2018 03:20:23 -0700 (PDT) X-Received: by 2002:a1c:815:: with SMTP id 21-v6mr13637999wmi.151.1531218022929; Tue, 10 Jul 2018 03:20:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:4151:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 03:20:22 -0700 (PDT) In-Reply-To: References: From: Aniket Pandey Date: Tue, 10 Jul 2018 15:50:22 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Fwd: [GSoC-18] Regression Test-Suite for Audit Framework [Week-8] To: soc-status@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 10:20:25 -0000 Hello all, I had been traveling for the last couple of days so couldn't update you all about my progress earlier. This week, I was able to create regression tests for sysctl(3), sysarch(2), cap_getmode(2), cap_enter(2) completely and audit(2) & jail(2) in failure mode. Also, in the previous mail, I had mentioned about setpriority(2) being in the "miscellaneous" audit class. Well, it turns out that I had not carefully looked at the section in which the specific event-class mapping was listed. setpriority(2) is exclusively a process-control system call. It was mentioned under the section of deprecated Darwin audit events which might conflict with Solaris mapping, later on, so that essentially rules out setpriority(2) being a miscellaneous audit event. For sysarch(2), I had to consider different architectures on which it would be called. sysarch(2) is included within which in turn includes the header for respective architecture, for my case, . On further analysis of supported machine instructions, I could only come up with possible testing scenarios for AMD64, i386, ARM, and MIPS. For Sparc64, ARM64 & PowerPC, I could either not find any safe machine instruction or none existed for them. To write the tests, I followed the strategy of using the macros which were defined in the , that would generate only those tests which were supported by the architecture in which the tests were compiled. All macros retrieved some info about the system, so they can be considered safe. Currently, the tests are under review and you can find the respective macro used here[1]. cap_getmode(2) and sysctl(3) were cakewalks as I had to just check whether Capsicum is enabled in the system or not (for the former) and use the standard sysctl to retrieve the maximum allowed processes using KERN_MAXPROC (for the later). With cap_enter(2), I again faced the intermittency issues. With a lot of debugging and help from Alan, we figured out that auditpipe(4) gets buffered when capability mode is entered. Hence, auditpipe does not show anything after fork(2) is called (Yes, I had to call cap_enter() from a child process since we can't put the main test in capability mode :P). A solution was to flush the auditpipe(4) right after cap_enter(2) is called, using a provided ioctl AUDITPIPE_FLUSH, that allowed cap_enter(2) to show up after the noise is cleaned. The updated tests for capability mode syscalls can be found here [2]. In the coming weeks, I'll try to convert the regression tests[3] for auditpipe(4) itself in ATF. And will have a look at the ways in which we can test auditdistd(8) and auditreduce(1). Thank you, With best regards, Aniket Pandey [1] https://reviews.freebsd.org/D16116 [2] https://reviews.freebsd.org/D16099 [3] https://github.com/freebsd/freebsd/blob/master/ tools/regression/audit/audit_pipe_ioctl/audit_pipe_ioctl.c