From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751169AbbIBFcN (ORCPT ); Wed, 2 Sep 2015 01:32:13 -0400 Received: from smtp106.biz.mail.bf1.yahoo.com ([98.139.244.54]:29973 "EHLO smtp106.biz.mail.bf1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750743AbbIBFcL (ORCPT ); Wed, 2 Sep 2015 01:32:11 -0400 X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MlAMzfMVM1mMCsZVNbCKYzrAPqA_o53iN_oc2XcWkBPiSeN LLSCOIBprPd3bguyfyu7g5fg.Ggz7u4i8_KumJH7t69Y6DaCI6qSs2xVr0zc oCuapQfR9KATBaPZjm2..0jYbKdahFwOANyXv5QhrFNH5Hor7kzXWAPkUrOF AsHduW5bxbhR09aIQwrWRlNggQ38ckEX2m8YxtI9UXiwHGUvo6t_xCD6WH7V ULGiSMY0RTZc82BRzLycBk1BeXT53Es9CZXGc6X7yPfrF6F2zFGrySjS9hrW Ig_WyC5LKpqi2FQdVUx26CtDeKLlL6OFZN2v_8dipAT1rPcSKIOypsXV.u04 PFs.Ml1q9551sRYloRuDIaIZoAh5NvMmoyMC1opFljvSPJ4z6X2VJeQlehZz VtNTQ8BOIBeMzVo9loqIsIISArL9zaEFKvJtOepyODAPczcgzhCtIMWkhKvs ZI_NZAYzFD_qPcWseO97NGnqkRSV7rl5sSwanFm5htEOY_CcquZoqDorO8Fc wxSoMmo6JWNTT6vN1CDhBrW70CMpwgAIs X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [PATCH] security: smack: Add support automatic Smack labeling To: jonghwa3.lee@samsung.com, Lukasz Pawelczyk , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org 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> <55E55B6A.1020903@samsung.com> Cc: james.l.morris@oracle.com, serge@hallyn.com, sangbae90.lee@samsung.com, inki.dae@samsung.com, Casey Schaufler From: Casey Schaufler Message-ID: <55E689D1.8050004@schaufler-ca.com> Date: Tue, 1 Sep 2015 22:32:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E55B6A.1020903@samsung.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/1/2015 1:01 AM, jonghwa3.lee@samsung.com wrote: > 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. The problem is that you're fixing the problem in the wrong place. I see that there is an issue, but there are several ways you could address it in udev. You could change udev so that instead of creating the device and changing it's Smack label you could create the device with a "-not-yet" suffix, change it's Smack label, then rename it to the proper name. There are other approaches as well. > Do you think that is just userspace's affair and couldn't be solved with > kernel's help? It *can* be fixed with the kernel's help, but it shouldn't. > I gently ask your comments. > > Thanks, > Jonghwa > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >