From owner-soc-status@freebsd.org Tue Jul 10 11:23:27 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 C3C261041BCA for ; Tue, 10 Jul 2018 11:23:27 +0000 (UTC) (envelope-from aniket.ezio41@gmail.com) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (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 44849714FE; Tue, 10 Jul 2018 11:23:27 +0000 (UTC) (envelope-from aniket.ezio41@gmail.com) Received: by mail-ed1-f45.google.com with SMTP id d17-v6so4223076eds.11; Tue, 10 Jul 2018 04:23:27 -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:from:date:message-id:subject:to:cc; bh=LOclLuiG5RjVb3KPTDmSUIS728OyKz2QcUy/4oCIoTc=; b=JR2INLIwLPGnPuDhWaBDvqrcIDS8jH0ssrobzXwRW/BTRu99bt3dg1Abw85Tvkb+wR NWKoj7oS5rgzxlbtE1CrOBCQPRL+lBNElt6bUIf1ycsSnX1lyUfsoHy0rWp2EScEz7wH HXSEDBfy0Wl6k9pvJH9Fo+KzzEAhqOYyJccE2tIiqV6BilTCoVDeY7KqXoIag4NpfirG KCzYqYqaWXURZSYDohqwTroxw/p32j2CgtSk1WC1doCVhw+9SkTVIlV9bUZH/WWtyqlz MZGRgd7ZIzk7z3KSmnboXTotMUL/HrhThVCIHMJQBGEPAVBMoDELpH/ZMU8aGytRPpWI RXmg== X-Gm-Message-State: APt69E1cQUWQ5Qzu7prIELH1hVSSZWLfpbNtMPcZ7hli7WpGFKYNV+tK SvJBZHsgzbs2NFRZODF/mvnwYu80 X-Google-Smtp-Source: AAOMgpdXAGsHSSTrs4yAP4bzIXO23zkbfJvKNr++NUpTyjNgBAx8S2oLg0M6Ri6tDI8khbYBktGcgA== X-Received: by 2002:a50:b410:: with SMTP id b16-v6mr14113191edh.190.1531214624077; Tue, 10 Jul 2018 02:23:44 -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 b22-v6sm8228596edn.0.2018.07.10.02.23.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 02:23:43 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id z6-v6so13050606wma.0; Tue, 10 Jul 2018 02:23:43 -0700 (PDT) X-Received: by 2002:a1c:ec06:: with SMTP id k6-v6mr15424529wmh.39.1531214623417; Tue, 10 Jul 2018 02:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:4151:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 02:23:43 -0700 (PDT) From: Aniket Pandey Date: Tue, 10 Jul 2018 14:53:43 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: [GSoC-18] Regression Test-Suite for Audit Framework [Week-8] To: soc-status@freebsd.org Cc: Alan Somers , George Neville-Neil , robert.watson@cl.cam.ac.uk 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 11:23:28 -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