From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755353AbbIAIBz (ORCPT ); Tue, 1 Sep 2015 04:01:55 -0400 Received: from mailout1.samsung.com ([203.254.224.24]:51049 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753971AbbIAIBx (ORCPT ); Tue, 1 Sep 2015 04:01:53 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee690-f796f6d000005054-e9-55e55b6fadbd Content-transfer-encoding: 8BIT Message-id: <55E55B6A.1020903@samsung.com> Date: Tue, 01 Sep 2015 17:01:46 +0900 From: jonghwa3.lee@samsung.com User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Lukasz Pawelczyk , Casey Schaufler , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Cc: james.l.morris@oracle.com, serge@hallyn.com, sangbae90.lee@samsung.com, inki.dae@samsung.com Subject: Re: [PATCH] security: smack: Add support automatic Smack labeling References: <1440640704-21730-1-git-send-email-jonghwa3.lee@samsung.com> <1440640704-21730-2-git-send-email-jonghwa3.lee@samsung.com> <55E09B2E.3040805@schaufler-ca.com> <55E3F0A2.2070102@samsung.com> <1441029540.2335.2.camel@samsung.com> In-reply-to: <1441029540.2335.2.camel@samsung.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsWyRsSkUDc/+mmowZrtyhb3tv1is5h0fwKL Rd/jIIszkxYyWVzeNYfN4kPPIzaL458Oslicv3CO3YHD49ruSI+PT2+xePRtWcXocXT/IjaP z5vkAlijuGxSUnMyy1KL9O0SuDJuX29lKZguUbHh60SmBsbZwl2MnBwSAiYSi5Y8YoewxSQu 3FvPBmILCaxglFjV5w9TM+XiVZYuRi6g+FJGie+PmphAErwCghI/Jt8DSnBwMAvISxy5lA1h qktMmZILUf6AUWL+m11Q5VoSz44tYgGxWQRUJRacmwwWZxOQk3jb9I0RxBYVSJA4fvYHE0iz iMBCRom5F6+BHccskCQxbc8XsAZhAS+JVU8usENs+MIoceHXFLCpnAJGEu3nFzGDJCQErrFL bD/0iwlinYDEt8mHwC6VEJCV2HSAGeIzSYmDK26wTGAUm4Xkn1kI/8xC+GcBI/MqRtHUguSC 4qT0IhO94sTc4tK8dL3k/NxNjMDIO/3v2YQdjPcOWB9iFOBgVOLh7fj4JFSINbGsuDL3EKMp 0A0TmaVEk/OB8Z1XEm9obGZkYWpiamxkbmmmJM77WupnsJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGtCNSDuoPM+SkQms5TrCXBfiYqe/ie8wXwvTaO2zi7gvh52usGJmzrz5amj59NXfd 3KOMXo35W8S2sLz1uH1v7xntRvHkKPvb263Oi2/k+O1+QkS+t63s27eJV/cs+6DgKZvze33s hplNsaH1uyzZQiUWxCz6OzGk5UiEpnmZYGvu3x96y44qsRRnJBpqMRcVJwIABPjGqbcCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsVy+t9jAd386KehBhv/yVrc2/aLzWLS/Qks Fn2PgyzOTFrIZHF51xw2iw89j9gsjn86yGJx/sI5dgcOj2u7Iz0+Pr3F4tG3ZRWjx9H9i9g8 Pm+SC2CNamC0yUhNTEktUkjNS85PycxLt1XyDo53jjc1MzDUNbS0MFdSyEvMTbVVcvEJ0HXL zAE6RUmhLDGnFCgUkFhcrKRvh2lCaIibrgVMY4Sub0gQXI+RARpIWMOYcft6K0vBdImKDV8n MjUwzhbuYuTkkBAwkZhy8SoLhC0mceHeerYuRi4OIYGljBLfHzUxgSR4BQQlfky+B1TEwcEs IC9x5FI2hKkuMWVKLkT5A0aJ+W92QZVrSTw7tghsJouAqsSCc5PB4mwCchJvm74xgtiiAgkS x8/+YAJpFhFYyCgx9+I1dpAEs0CSxLQ9X8AahAW8JFY9ucAOseELo8SFX1PApnIKGEm0n1/E PIFRYBaS+2Yh3DcL4b4FjMyrGCVSC5ILipPSc43yUsv1ihNzi0vz0vWS83M3MYLj+5n0DsbD u9wPMQpwMCrx8HZ8fBIqxJpYVlyZe4hRgoNZSYS3MvJpqBBvSmJlVWpRfnxRaU5q8SFGU6AH JzJLiSbnA1NPXkm8obGJmZGlkbmhhZGxuZI4bw470ByB9MSS1OzU1ILUIpg+Jg5OqQbGtr8Z fL5930y7DpSm/FvRqe63U9rEkePKspgO3kWlpTafX4Wu6X0552BT28HXrE+X3zXq+nFEYuWC j4pKog1OcTtLtTP1zJ9uuhCrZqGU8FP+f53p5k+hBV43LqxIf578r9HmyQVdl7r29ONOYX8T VI9P2H4pSyXKuzTj9IqyK+t3ab0zK+5XYinOSDTUYi4qTgQAkIesfQUDAAA= DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015년 08월 31일 22:59, Lukasz Pawelczyk wrote: > On pon, 2015-08-31 at 15:13 +0900, jonghwa3.lee@samsung.com wrote: >> A rule is defined for a process, 'process A', in smack rule table. >> >> ... >> Process A device::A arwx- >> ... >> >> The object 'device::A' will be used to a device node that 'process A' >> will access. >> However when the target device node is created it's labeled with >> default label >> which is inherited from any of filesystem, ancestor, or creating >> process. >> Let's say the default object label for devtmpfs is '_' which allows >> only read and >> write access. So we need the specific labeling by the authorized >> process as like >> udevd for the devtmpfs. >> >> In normal, smack label and access control follow the sequences, >> >> 1. Kernel module driver loaded >> 2. New device node is created (/dev/aaa , '_') >> 3. Udevd gets uevent and appies udev rule (/dev/aaa, 'device::A') >> 4. 'Process A' accesses the device node ('Process A' ---> >> 'device::A', MAY_WRITE) >> 5. Access is permitted. >> >> However, when labeling isn't done in proper time, result will be >> different, >> >> 1. Kernel module driver loaded >> 2. New device node is created (/dev/aaa , '_') >> 3. 'Process A' accesses the device node ('Process A' ---> '_', >> MAY_WRITE) >> 4. Access is prohibited >> >> Can this situation be handled in current Smack subsystem? >> If so, could you give me an idea how to handle it. > This doesn't seem to be a Smack problem. This isn't even a kernel > problem. It's userspace race. You should wait for a proper udev event > that notifies after all udev rules are applied. > > I think there are 2 udev events. One that notifies that a device has > been added. Second that notifies where all the rules for the device has > been applied. You need to use the second one. > > > Yes you're right, it's not a problem of neither Smack nor kernel. However it will help to resolve the problem if there is a proper way to label handled by kernel at least for files created by kernel.(e.g. device node) I'm not sure whether there is a uevent for completion of applying rule. (I couldn't catch any of such uevent with udevadm.) However even there is, I think kernel side labeling has obvious advantages. The every new files need proper labeling before working under Smack. The files created by user application can be labeled by the same process at once. So it doesn't need to consider delayed labeling before access. However, the files created by kernel has to wait user space's control to be used. The timing of user space's labeling is not precised. It can be delayed indefinitely. Yes it's userspace race, but if kernel help it, It can prevent such issues. My proposal might be not quite fancy. (It could degrade system's performance severely as like Casey pointed out) But I'd like to ask whether this attempt is useless. Do you think that is just userspace's affair and couldn't be solved with kernel's help? I gently ask your comments. Thanks, Jonghwa