From owner-freebsd-hackers@freebsd.org Mon Jul 17 20:42:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85975DA0292 for ; Mon, 17 Jul 2017 20:42:37 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 0F9EC70935 for ; Mon, 17 Jul 2017 20:42:37 +0000 (UTC) (envelope-from mber2015@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id p204so1057291wmg.1 for ; Mon, 17 Jul 2017 13:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=yUO7/haaukeHGcqXvz8M7fZY+fo5+VhICLekTabtBxQ=; b=NWcVCzLd2Br4PpdiSyjbgugifRLeitqW+IrCBb1ZppCAWTZDHsK0N+AVTwEvOS6Uaf hgV/c5qwzPnUE+71L8NVVhAY4xSz+PXUaRSIvOO3xtgYoZIuberBawosIJ4s3Iy1QJug SAPqCBaTd3TV94BZRDBTY8CoVqp5gtKqqEXuGX9pikLNy0xmhFTLGA/k29nu2167uixs 5PMUmQKQNY4q5qmHCGh1pGiw2qxZQ2HCoLBrRASRrl32i6g6EakgGvWjHpcxd/RUEUoH VVc8ctzWJNMpRJfYlTlyVnwbBGJ2qvumzEDF7JllnvAJmCXxVkhsBuPRiYPhL/4o2D2c 6L7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=yUO7/haaukeHGcqXvz8M7fZY+fo5+VhICLekTabtBxQ=; b=Oar4vjls9RtV9F6WARKBY8fNfP+ZQfeSbWdchWxQE8iqaFUy4fMX2VWQ59/VPJjx4e mMbsYpHULp39LGUKMBHmLLI+dAontsLIwRSqrdi97u3N7sEHA2cE13keN6l8taWWuQs8 pYorK9BbCaGZFQUf5+NGvxRDXHwJ06Os4RMPcvrN/9x8xApF1i2eL1JRDVjlyudRFFhL gpfXiq/tpMgGeGRYs4t1OMnWPpjwIIEIc9xsagyajGMKUP4Aa+QtK46D90JfCzVIPfzR 5Rz7Ss8PLoiQt4FpFzRx8EkU3Ip34eliskhMJlqETKbXInBp3pCpt+qV+zKmURtjkeiw WCMg== X-Gm-Message-State: AIVw111FPpB+POAqAHOSUqHQwA97QlHKasBRDW7gT97N1vJsK9I4xJqu M7RpdCk5GPpSMW47Crk= X-Received: by 10.28.156.20 with SMTP id f20mr5356407wme.17.1500324154959; Mon, 17 Jul 2017 13:42:34 -0700 (PDT) Received: from mb.tns.cz ([92.43.24.116]) by smtp.gmail.com with ESMTPSA id 143sm15767202wmg.9.2017.07.17.13.42.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 13:42:34 -0700 (PDT) Sender: Martin Beran To: freebsd-hackers@freebsd.org From: Martin Beran Subject: mac_sofi: a proof of concept MAC module Message-ID: Date: Mon, 17 Jul 2017 22:42:33 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:42:37 -0000 Hello, I created an initial proof-of-concept implementation of a new Mandatory Access Control kernel module. It is called SOFI (Subjects and Objects with Floating Integrity). Source code is at https://github.com/martin-beran/mac_sofi. It is written and tested on FreeBSD 10.3, but it should be usable on newer releases too. The SOFI security model combines access control by ACLs and capabilities with automatic modification of process and data integrity according to data flow. Each subject (usually a process that executes an operation, for example, a system call) and object (a target of the operation, for example, a file being accessed) has its integrity value, which is a set of atomic integrity attributes. A subject or an object can be either a reader or a writer for a particular operation, depending on the direction of information flow between them. First, the subject's integrity is compared to the object's ACL in order to decide whether the operation should be allowed or denied. If allowed, the reader's integrity (subject in read, object in write) is modified to the lower bound (intersection) of reader's and writers's integrities. Then the operation is performed. The main idea is that accessing low-integrity data (a file downloaded from an untrusted source) makes a process untrusted and prevents its further access to high-integrity data (reading a file with personal information or changing an executable file). To be practical, integrity reduction of readers can be controlled by a testing function, which can prevent removing some integrity attributes from a reader. For example, a downloaded installation image file is assigned a low integrity. But if a checker program, which has high integrity, reads the file and verifies its digital signature, the program's integrity is not degraded, so it can pass the image to an installer as high-integrity data. There is also an integrity granting function, which can add some integrity attributes from a writer to a reader. It is essentially similar to the set-uid bit on executables. More technical description of the SOFI algorithm is contained in the mac_sofi.h header file. The implementation is an initial proof-of-concept. It demonstrates basic principles of the SOFI model, but only file open, access check, read, and write operations, as well as MAC label manipulation entry points of the MAC framework are implemented. The internal data structures are inefficient due to my unfortunate initial decision to combine a fixed-size integrity and some variable-size data into a single MAC label structure. It is my first attempt to create a nontrivial kernel module, so I expect bugs related to locking and memory management. There are also many open correctness-related questions, especially regarding memory-mapped data, multithreading, and blocking read operations. I would appreciate any comments on both the SOFI model and on my implementation. -- Martin Beran