From owner-soc-status@freebsd.org Mon May 28 02:10:30 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 A3A28EF41DC for ; Mon, 28 May 2018 02:10:30 +0000 (UTC) (envelope-from aniket.ezio41@gmail.com) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.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 1C17176D6E; Mon, 28 May 2018 02:10:29 +0000 (UTC) (envelope-from aniket.ezio41@gmail.com) Received: by mail-wm0-f49.google.com with SMTP id m129-v6so27939672wmb.3; Sun, 27 May 2018 19:10:29 -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=aqpO4/9K72dcN6UwLws8cu0IGOIt10Oyuko2g6QVbo4=; b=HPG8yH7JG2gcMgemdfogN7yiRO06KlyfZrkC7hyCRMyZB8nK/QEDKoDN48NMYOolKe hGgwljm+NOeSDjB0t+CYfAnVQhPHbPIEygbA8vIW1ZtCvR3RwzZaGv/MJkRM046CcP66 E8QCIL3ZpLgpQxh6BZGKTMqM+ddTPNjl/0jmeTSNqr6XWFGf3U4vzlXF7Fe4fKO/ZNHC y5bNE8EvkGNoWCVzrcz0cxa4l6yMsW+hI13R36ojj+PgLtypfv+5W9XuYQ31DHjelUnG /L6bTSbSx/lHlg9FpF9PFJHaGgIE/Mv0FA9XnNx70IebVeioeMyTpEGm3q6M4z6sOg5i u5Mg== X-Gm-Message-State: ALKqPwe6pwwB5yhlsyCmlEnPJeG5w88mjSc8403P76PuQ9qOgUTpZpry ANPoIfXnzf5zfw5pCA3nVi35fMNB X-Google-Smtp-Source: AB8JxZrvOPy2JpG6eFZzHjMzKlrWjQVH6/jZCPGkmebhKNysFn+UFHPHfCkvfH2wPxVePXYMrWveMQ== X-Received: by 2002:a50:c119:: with SMTP id l25-v6mr13113194edf.188.1527473422666; Sun, 27 May 2018 19:10:22 -0700 (PDT) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com. [74.125.82.53]) by smtp.gmail.com with ESMTPSA id j22-v6sm15711635edq.92.2018.05.27.19.10.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 May 2018 19:10:22 -0700 (PDT) Received: by mail-wm0-f53.google.com with SMTP id o78-v6so28069512wmg.0; Sun, 27 May 2018 19:10:22 -0700 (PDT) X-Received: by 2002:a1c:5403:: with SMTP id i3-v6mr7048693wmb.37.1527473422026; Sun, 27 May 2018 19:10:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:adcf:0:0:0:0:0 with HTTP; Sun, 27 May 2018 19:10:21 -0700 (PDT) From: Aniket Pandey Date: Mon, 28 May 2018 07:40:21 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: [GSoC-18] Regression Test-Suite for Audit Framework [Week-2] To: soc-status@freebsd.org Cc: asomers@freebsd.org, robert.watson@cl.cam.ac.uk, gavin@freebsd.org, George Neville-Neil Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.26 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: Mon, 28 May 2018 02:10:30 -0000 Hello all, At the end of the week 2, as promised, I was able to finish off the tests for network APIs and complete the remaining test cases for audit classes concerned with File I/O and device management. I also studied about "Inter Process Communication" within an Operating System and how best to audit the syscalls present within IPC audit class. So a total of 115 atf-c(3) test-cases spanning over 6 audit classes {fm, cl, nt, io, ex, ip} were developed during this week. Milestones and issues encountered ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1) Fixing the panic mentioned in the previous mail, brought up another consistent and reproducible kernel panic. This time, whenever auditd(8) was already running and the system-wide audit mask was set as "pc" (process control), trying to list the contents of a directory using "exa-0.8.0" caused another panic. The stack trace showed the involvement of an audit lookup function. ( https://pastebin.com/b68k27iw ) 2) On trying to audit execve(2) system call, we noticed that even on the successful invocation of execve, audit record showed "return,failure : Unknown error" which was quite unexpected. On further analysis, we concluded that since execve(2) overlays the calling process on successful execution, the audit(4) doesn't get any return status so it essentially prints out the exception case in the errno lookup here: https://github.com/freebsd/freebsd/blob/master/sys/security/audit/bsm_errno.c#L728 3) While writing tests for network socket system calls, I had to overcome a unique challenge. Since Kyua executes every test-case as a separate process and that it's not possible to share the state between the test cases, I had to somehow integrate both client and server APIs within a single test case body. Now the options I could think of were to either fork the client out of the main process after listen(2) has been called, or simply use different threads for both. However, Alan suggested a much better approach, simply make the server non-blocking and create the client socket right before connect(2) is called. With the server waiting for connection by the time client calls a connect(2), we would be able to get the successful connection within the same program in a single thread. [ Note: Even though this method is successful in FreeBSD, it sometimes returns EWOULDBLOCK in Linux ] Although I could get a successful connection using this approach, I still had to audit recv(2), recvfrom(2) which are blocking, after they successfully receive data from their counterparts, i.e send(2) and sendto(2). But since I was calling the recv(2) from the server which was already non-blocking, I couldn't get a successful audit of these functions. On further research, I came across some threads on reddit which mentioned doing synchronous I/O multiplexing on the client socket using select(2) to ensure that the socket is ready for reading, i.e recv(2), recvfrom(2) can successfully exit. This allowed me to audit all possible scenarios of network socket system calls! Here is the test-case which checks the audit of recvfrom(2): https://github.com/aniketp/AuditTestSuite/blob/master/src/network.c#L877 4) Post that, I've added about 51 test cases for system calls concerned with manipulating message queues, shared memory segments and semaphore sets as a part of IPC audit class. I would keep adding the tests and hopefully, finish off "ip" audit events within a couple of days. 5) I've also created a differential revision on shifting "struct auditpipe_ioctl_preselect" from to since its members, i.e "au_mask_t" and "au_id_t" are defined within the later header file. It is currently under review. Status ~~~~~~ So far, I've been able to create 421 test-cases spanning over 11 test programs for 107 system calls of {"fc", "fr", "fw", "fd", "fa", "fm", "cl", "io", "ex", "nt", "ip"} audit classes in 8449 SLOC. The tests are passing apart from a few expected failures from syscalls which are supposed to be audited but are not. The test result can be seen here > https://pastebin.com/eMPUNfrX I'll hopefully be able to finish off my proposed work (explicit system call testing) within a week and then I can work on testing some other important aspects of the audit system as a stretch goal. Bugs Reported (this week) ~~~~~~~~~~~ 1) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228444 [Kernel panic due to "exa"] 2) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228470 [ location of struct] Differential Revisions ~~~~~~~~~~~~~~~~ 1) https://reviews.freebsd.org/D15561 Thank you, With Best Regards, Aniket Pandey P.S: The discussion regarding the project takes place on #audit-testing channel on efnet. If anybody is interested in the discussions and would like to suggest some improvements in the current approach, please feel free to join the channel!