From mboxrd@z Thu Jan 1 00:00:00 1970 From: valdis.kletnieks@vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 25 Nov 2018 22:26:41 -0500 Subject: Kernel default security configuration - how it affects LSM policy? In-Reply-To: <2782681542810050@sas1-890ba5c2334a.qloud-c.yandex.net> References: <2782681542810050@sas1-890ba5c2334a.qloud-c.yandex.net> Message-ID: <134786.1543202801@turing-police.cc.vt.edu> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Wed, 21 Nov 2018 17:20:50 +0300, Lev Olshvang said: > So the questioned config option seems obsolete ? > Wheher LSM always consulted last ? If an LSM is configured/loaded, it is always consulted *after* applying standard DAC file permission bits checks. (Discretionary Access Control- the owner of the file/object is allowed to make their own decisions) LSMs are always restrictive MAC (Mandatory access control - they are applied by the system regardless of what the user/owner wants) calls. Restrictive means they can only prohibit a call that has already passed the DAC check, they cannot allow a call that would otherwise be failed by DAC. LSMs are called after DAC checks for a number of reasons. One big one is that when the LSM hooks were designed, the file permission checks were (and still are) incredibly cheap - 3-4 opcodes or so. So it makes sense to do the cheap check first, as things like SELinux or AppArmor take a lot more cycles to do the check. (There's also a few oddball corner cases where doing the MAC check first results in non-intuitive results) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omr1.cc.ipv6.vt.edu ([2607:b400:92:8300:0:c6:2117:b0e] helo=omr1.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gR7Xw-0001ZJ-QD for kernelnewbies@kernelnewbies.org; Sun, 25 Nov 2018 22:26:52 -0500 Received: from mr5.cc.vt.edu (mr5.cc.vt.edu [IPv6:2607:b400:92:8400:0:72:232:758b]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id wAQ3QncO004505 for ; Sun, 25 Nov 2018 22:26:49 -0500 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by mr5.cc.vt.edu (8.14.7/8.14.7) with ESMTP id wAQ3QiZm019205 for ; Sun, 25 Nov 2018 22:26:49 -0500 Received: by mail-qk1-f199.google.com with SMTP id w185so18297892qka.9 for ; Sun, 25 Nov 2018 19:26:49 -0800 (PST) From: valdis.kletnieks@vt.edu To: Lev Olshvang Subject: Re: Kernel default security configuration - how it affects LSM policy? In-Reply-To: <2782681542810050@sas1-890ba5c2334a.qloud-c.yandex.net> References: <2782681542810050@sas1-890ba5c2334a.qloud-c.yandex.net> Mime-Version: 1.0 Date: Sun, 25 Nov 2018 22:26:41 -0500 Message-ID: <134786.1543202801@turing-police.cc.vt.edu> Cc: linux-il , kernelnewbies List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5561260619606574770==" Errors-To: kernelnewbies-bounces@kernelnewbies.org Message-ID: <20181126032641.KxR83mi841AXh0xX86NWuZ5t3pT8Ptau307_ZDxTehs@z> --===============5561260619606574770== Content-Type: multipart/signed; boundary="==_Exmh_1543202801_2486P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1543202801_2486P Content-Type: text/plain; charset=us-ascii On Wed, 21 Nov 2018 17:20:50 +0300, Lev Olshvang said: > So the questioned config option seems obsolete ? > Wheher LSM always consulted last ? If an LSM is configured/loaded, it is always consulted *after* applying standard DAC file permission bits checks. (Discretionary Access Control- the owner of the file/object is allowed to make their own decisions) LSMs are always restrictive MAC (Mandatory access control - they are applied by the system regardless of what the user/owner wants) calls. Restrictive means they can only prohibit a call that has already passed the DAC check, they cannot allow a call that would otherwise be failed by DAC. LSMs are called after DAC checks for a number of reasons. One big one is that when the LSM hooks were designed, the file permission checks were (and still are) incredibly cheap - 3-4 opcodes or so. So it makes sense to do the cheap check first, as things like SELinux or AppArmor take a lot more cycles to do the check. (There's also a few oddball corner cases where doing the MAC check first results in non-intuitive results) --==_Exmh_1543202801_2486P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQEVAwUBW/tn8Y0DS38y7CIcAQKHxwgAkV8c8LoFuop6h+nnJglKOhj2+VhKx9kQ iOlA6DPT4b7KCayJxT/L+al+aYQqx8rGtUvjRZKx8vVXevWEqkB3913jJrkjOK8b KN3tOAHFoxQtnRtQj7vLAA9ee37OAmcTCkhvmsaYtk8HoqsS8Int+VvklvxP5Q0D 7HaxMASwywc++yzJOH0WzvJWcsUVWAiqz9V9AQnV4Y3RVvxdwxdhPb88U2bAVKkQ DDlaW4vV0hPoft/bVY7UcYWp0ikU6iv8+GGIgjE4wI/HCuogL3jjArzZDznSWGHl XCVDyk40RXHE7M6irNjB8KZuzuAPBin6pOWvS3EFy+knh1fBPUfBrg== =R+ql -----END PGP SIGNATURE----- --==_Exmh_1543202801_2486P-- --===============5561260619606574770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============5561260619606574770==--