Re: [PATCH] security: smack: Add support automatic Smack labeling
On 9/1/2015 1:01 AM, jonghwa3@samsung.com wrote:
> On 2015년 08월 31일 22:59, Lukasz Pawelczyk wrote:
>> On pon, 2015-08-31 at 15:13 +0900, jonghwa3@samsung.com wrote:
>>> A rule is defined for a process, 'process A', in smack rule table.
>>>
>>> ...
>>> Process Adevice::Aarwx-
>>> ...
>>>
>>> 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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] security: smack: Add support automatic Smack labeling
On 2015년 08월 31일 22:59, Lukasz Pawelczyk wrote:
> On pon, 2015-08-31 at 15:13 +0900, jonghwa3@samsung.com wrote:
>> A rule is defined for a process, 'process A', in smack rule table.
>>
>> ...
>> Process Adevice::Aarwx-
>> ...
>>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] security: smack: Add support automatic Smack labeling
On 2015년 08월 31일 22:59, Lukasz Pawelczyk wrote:
> On pon, 2015-08-31 at 15:13 +0900, jonghwa3@samsung.com wrote:
>> A rule is defined for a process, 'process A', in smack rule table.
>>
>> ...
>> Process Adevice::Aarwx-
>> ...
>>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] security: smack: Add support automatic Smack labeling
On 9/1/2015 1:01 AM, jonghwa3@samsung.com wrote:
> On 2015년 08월 31일 22:59, Lukasz Pawelczyk wrote:
>> On pon, 2015-08-31 at 15:13 +0900, jonghwa3@samsung.com wrote:
>>> A rule is defined for a process, 'process A', in smack rule table.
>>>
>>> ...
>>> Process Adevice::Aarwx-
>>> ...
>>>
>>> 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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] security: smack: Add support automatic Smack labeling
On pon, 2015-08-31 at 15:13 +0900, jonghwa3@samsung.com wrote:
> A rule is defined for a process, 'process A', in smack rule table.
>
> ...
> Process Adevice::Aarwx-
> ...
>
> 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.
--
Lukasz Pawelczyk
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] security: smack: Add support automatic Smack labeling
On 2015년 08월 29일 02:32, Casey Schaufler wrote:
> On 8/26/2015 6:58 PM, Jonghwa Lee wrote:
>> Current Smack object's label is always given by userspace.
>> So there might be a certain gap between the time of file creation
>> and the time of applying actual label. And because of the time gap,
>> it results unintended Smack denial time to time.
>>
>> If accessing a file occurs ahead of labeling, Smack module will check
>> the authority with uninitialized label and will prohibit the access
>> as a result. It shouldn't be happened labeling is done in proper time.
> The Smack label is assigned when the inode is created.
> The value will depend on the filesystem type, the state
> of transmute attributes, and the Smack label of the
> creating process. But it will always be assigned.
>
>> For the case that system can't gueratee that Smack labeling is done
>> before any other accesses to newly created file, this patch introdues
>> new interface called 'Automatic Smack labling'.
> The system guarantees that the Smack labeling is done
> before any other access can be attempted in all cases.
> Can you describe a situation where this does not occur?
>
Hi, Casey,
First of all, I`m thank you for review my humble patch.
I already explained the situation in cover letter but it seemed not enough.
(RFC cover : https://lkml.org/lkml/2015/8/26/782)
Let me explain it in detail. Here is the case,
A rule is defined for a process, 'process A', in smack rule table.
...
Process Adevice::Aarwx-
...
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.
Best regards,
Jonghwa Lee
>> The label can be defined before file creation with absolute path.
> You could in a pathname based system like AppArmor or TOMOYO,
> but Smack is an object based system. You can't count on the
> pathname to identify the object you care about. There are too
> many facilities that can manipulate the filesystem namespace.
> You have to deal with chroot and filesystem namespaces just to
> start.
>
> That, and the performance impact would be prohibitive.
>
>> Then, when target file is created in generic manner, the pre-defined
>> label is applied automatically at once.
>>
>> Pre-defined label format follows below form.
>>
>>
>>
>> And it can add new entry to autolabel table via 'autolabel' in smackfs.
>>
>>echo ' ' > /sys/fs/smackfs/autolabel
>>
>> To view entries of autolabel table,
>>
>>$cat /sys/fs/smackfs/autolabel
>>/dev/device00 Label:A
>>/run/userfile0 Label:B
>>
>> Signed-off-by: Jonghwa Lee
> Nacked-by: Casey Schaufler
>
>> ---
>> security/smack/Kconfig | 11
>> security/smack/smack.h | 23
>> security/smack/smack_lsm.c | 66 +
>> security/smack/smackfs.c | 136
>>
>> 4 files changed, 236 insertions(+)
>>
>> diff --git a/security/smack/Kconfig b/security/smack/Kconfig
>> index 271adae..002aa01 100644
>> --- a/security/smack/Kconfig
>> +++ b/security/smack/Kconfig
>> @@ -30,6 +30,17 @@ config SECURITY_SMACK_BRINGUP
>>"permissive" mode of other systems.
>>If you are unsure how to answer this question, answer N.
>>
>> +config SECURITY_SMACK_AUTOLABEL
>> +bool "Enable Automatic Smack Labeling"
>> +depends on SECURITY_SMACK
>> +default n
>> +help
>> + To remove out the gap between file creation and actual labeling,
>> + this option gives the additional interface for automatic labeling.
>> + With this option enabled, a file will posseses the assigned label
>> + in autolabel table at creation.
>> + If you are unsure how to answer this question, answer N.
>> +
>> config SECURITY_SMACK_NETFILTER
>> bool "Packet marking using secmarks for netfilter"
>> depends on SECURITY_SMACK
>> diff --git a/security/smack/smack.h b/security/smack/smack.h
>> index fff0c61..8b7ee83 100644
>> --- a/security/smack/smack.h
>> +++
Re: [PATCH] security: smack: Add support automatic Smack labeling
On 2015년 08월 29일 02:32, Casey Schaufler wrote:
> On 8/26/2015 6:58 PM, Jonghwa Lee wrote:
>> Current Smack object's label is always given by userspace.
>> So there might be a certain gap between the time of file creation
>> and the time of applying actual label. And because of the time gap,
>> it results unintended Smack denial time to time.
>>
>> If accessing a file occurs ahead of labeling, Smack module will check
>> the authority with uninitialized label and will prohibit the access
>> as a result. It shouldn't be happened labeling is done in proper time.
> The Smack label is assigned when the inode is created.
> The value will depend on the filesystem type, the state
> of transmute attributes, and the Smack label of the
> creating process. But it will always be assigned.
>
>> For the case that system can't gueratee that Smack labeling is done
>> before any other accesses to newly created file, this patch introdues
>> new interface called 'Automatic Smack labling'.
> The system guarantees that the Smack labeling is done
> before any other access can be attempted in all cases.
> Can you describe a situation where this does not occur?
>
Hi, Casey,
First of all, I`m thank you for review my humble patch.
I already explained the situation in cover letter but it seemed not enough.
(RFC cover : https://lkml.org/lkml/2015/8/26/782)
Let me explain it in detail. Here is the case,
A rule is defined for a process, 'process A', in smack rule table.
...
Process Adevice::Aarwx-
...
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.
Best regards,
Jonghwa Lee
>> The label can be defined before file creation with absolute path.
> You could in a pathname based system like AppArmor or TOMOYO,
> but Smack is an object based system. You can't count on the
> pathname to identify the object you care about. There are too
> many facilities that can manipulate the filesystem namespace.
> You have to deal with chroot and filesystem namespaces just to
> start.
>
> That, and the performance impact would be prohibitive.
>
>> Then, when target file is created in generic manner, the pre-defined
>> label is applied automatically at once.
>>
>> Pre-defined label format follows below form.
>>
>>
>>
>> And it can add new entry to autolabel table via 'autolabel' in smackfs.
>>
>>echo ' ' > /sys/fs/smackfs/autolabel
>>
>> To view entries of autolabel table,
>>
>>$cat /sys/fs/smackfs/autolabel
>>/dev/device00 Label:A
>>/run/userfile0 Label:B
>>
>> Signed-off-by: Jonghwa Lee
> Nacked-by: Casey Schaufler
>
>> ---
>> security/smack/Kconfig | 11
>> security/smack/smack.h | 23
>> security/smack/smack_lsm.c | 66 +
>> security/smack/smackfs.c | 136
>>
>> 4 files changed, 236 insertions(+)
>>
>> diff --git a/security/smack/Kconfig b/security/smack/Kconfig
>> index 271adae..002aa01 100644
>> --- a/security/smack/Kconfig
>> +++ b/security/smack/Kconfig
>> @@ -30,6 +30,17 @@ config SECURITY_SMACK_BRINGUP
>>"permissive" mode of other systems.
>>If you are unsure how to answer this question, answer N.
>>
>> +config SECURITY_SMACK_AUTOLABEL
>> +bool "Enable Automatic Smack Labeling"
>> +depends on SECURITY_SMACK
>> +default n
>> +help
>> + To remove out the gap between file creation and actual labeling,
>> + this option gives the additional interface for automatic labeling.
>> + With this option enabled, a file will posseses the assigned label
>> + in autolabel table at creation.
>> + If you are unsure how to answer this question, answer N.
>> +
>> config SECURITY_SMACK_NETFILTER
>> bool "Packet marking using secmarks for netfilter"
>> depends on SECURITY_SMACK
>> diff --git a/security/smack/smack.h b/security/smack/smack.h
>> index fff0c61..8b7ee83 100644
Re: [PATCH] security: smack: Add support automatic Smack labeling
On pon, 2015-08-31 at 15:13 +0900, jonghwa3@samsung.com wrote:
> A rule is defined for a process, 'process A', in smack rule table.
>
> ...
> Process Adevice::Aarwx-
> ...
>
> 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.
--
Lukasz Pawelczyk
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] security: smack: Add support automatic Smack labeling
On 8/26/2015 6:58 PM, Jonghwa Lee wrote:
> Current Smack object's label is always given by userspace.
> So there might be a certain gap between the time of file creation
> and the time of applying actual label. And because of the time gap,
> it results unintended Smack denial time to time.
>
> If accessing a file occurs ahead of labeling, Smack module will check
> the authority with uninitialized label and will prohibit the access
> as a result. It shouldn't be happened labeling is done in proper time.
The Smack label is assigned when the inode is created.
The value will depend on the filesystem type, the state
of transmute attributes, and the Smack label of the
creating process. But it will always be assigned.
>
> For the case that system can't gueratee that Smack labeling is done
> before any other accesses to newly created file, this patch introdues
> new interface called 'Automatic Smack labling'.
The system guarantees that the Smack labeling is done
before any other access can be attempted in all cases.
Can you describe a situation where this does not occur?
> The label can be defined before file creation with absolute path.
You could in a pathname based system like AppArmor or TOMOYO,
but Smack is an object based system. You can't count on the
pathname to identify the object you care about. There are too
many facilities that can manipulate the filesystem namespace.
You have to deal with chroot and filesystem namespaces just to
start.
That, and the performance impact would be prohibitive.
> Then, when target file is created in generic manner, the pre-defined
> label is applied automatically at once.
>
> Pre-defined label format follows below form.
>
>
>
> And it can add new entry to autolabel table via 'autolabel' in smackfs.
>
>echo ' ' > /sys/fs/smackfs/autolabel
>
> To view entries of autolabel table,
>
>$cat /sys/fs/smackfs/autolabel
>/dev/device00 Label:A
>/run/userfile0 Label:B
>
> Signed-off-by: Jonghwa Lee
Nacked-by: Casey Schaufler
> ---
> security/smack/Kconfig | 11
> security/smack/smack.h | 23
> security/smack/smack_lsm.c | 66 +
> security/smack/smackfs.c | 136
>
> 4 files changed, 236 insertions(+)
>
> diff --git a/security/smack/Kconfig b/security/smack/Kconfig
> index 271adae..002aa01 100644
> --- a/security/smack/Kconfig
> +++ b/security/smack/Kconfig
> @@ -30,6 +30,17 @@ config SECURITY_SMACK_BRINGUP
> "permissive" mode of other systems.
> If you are unsure how to answer this question, answer N.
>
> +config SECURITY_SMACK_AUTOLABEL
> + bool "Enable Automatic Smack Labeling"
> + depends on SECURITY_SMACK
> + default n
> + help
> + To remove out the gap between file creation and actual labeling,
> + this option gives the additional interface for automatic labeling.
> + With this option enabled, a file will posseses the assigned label
> + in autolabel table at creation.
> + If you are unsure how to answer this question, answer N.
> +
> config SECURITY_SMACK_NETFILTER
> bool "Packet marking using secmarks for netfilter"
> depends on SECURITY_SMACK
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index fff0c61..8b7ee83 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Use IPv6 port labeling if IPv6 is enabled and secmarks
> @@ -106,6 +107,9 @@ struct inode_smack {
> struct smack_known *smk_inode; /* label of the fso */
> struct smack_known *smk_task; /* label of the task */
> struct smack_known *smk_mmap; /* label of the mmap domain */
> +#ifdef CONFIG_SECURITY_SMACK_AUTOLABEL
> + struct smack_auto_label *smk_auto;
> +#endif
> struct mutexsmk_lock; /* initialization lock */
> int smk_flags; /* smack inode flags */
> };
> @@ -480,4 +484,23 @@ static inline void smk_ad_setfield_u_net_sk(struct
> smk_audit_info *a,
> }
> #endif
>
> +#ifdef CONFIG_SECURITY_SMACK_AUTOLABEL
> +struct smack_auto_label {
> + bool disabled;
> + char *fpath;
> + struct list_head entry;
> + struct smack_known *label;
> + struct inode *inode;
> +};
> +
> +extern struct list_head smack_autolabel_list;
> +extern struct mutex smack_autolabel_lock;
> +
> +extern struct smack_known *smk_inode_bind_autolabel(struct inode *);
> +extern void smk_inode_unbind_autolabel(struct inode *);
> +#else
> +#define smk_inode_bind_autolabel(inode) NULL
> +#define smk_inode_unbind_autolabel(inode)do { } while (0)
> +#endif /* CONFIG_SECURITY_SMACK_AUTOLABEL */
> +
> #endif /* _SECURITY_SMACK_H */
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 996c889..851e8b4 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
>
Re: [PATCH] security: smack: Add support automatic Smack labeling
On 8/26/2015 6:58 PM, Jonghwa Lee wrote:
Current Smack object's label is always given by userspace.
So there might be a certain gap between the time of file creation
and the time of applying actual label. And because of the time gap,
it results unintended Smack denial time to time.
If accessing a file occurs ahead of labeling, Smack module will check
the authority with uninitialized label and will prohibit the access
as a result. It shouldn't be happened labeling is done in proper time.
The Smack label is assigned when the inode is created.
The value will depend on the filesystem type, the state
of transmute attributes, and the Smack label of the
creating process. But it will always be assigned.
For the case that system can't gueratee that Smack labeling is done
before any other accesses to newly created file, this patch introdues
new interface called 'Automatic Smack labling'.
The system guarantees that the Smack labeling is done
before any other access can be attempted in all cases.
Can you describe a situation where this does not occur?
The label can be defined before file creation with absolute path.
You could in a pathname based system like AppArmor or TOMOYO,
but Smack is an object based system. You can't count on the
pathname to identify the object you care about. There are too
many facilities that can manipulate the filesystem namespace.
You have to deal with chroot and filesystem namespaces just to
start.
That, and the performance impact would be prohibitive.
Then, when target file is created in generic manner, the pre-defined
label is applied automatically at once.
Pre-defined label format follows below form.
File path Smack Label
And it can add new entry to autolabel table via 'autolabel' in smackfs.
echo 'File path Smack Label' /sys/fs/smackfs/autolabel
To view entries of autolabel table,
$cat /sys/fs/smackfs/autolabel
/dev/device00 Label:A enabled
/run/userfile0 Label:B disabled
Signed-off-by: Jonghwa Lee jonghwa3@samsung.com
Nacked-by: Casey Schaufler ca...@schaufler-ca.com
---
security/smack/Kconfig | 11
security/smack/smack.h | 23
security/smack/smack_lsm.c | 66 +
security/smack/smackfs.c | 136
4 files changed, 236 insertions(+)
diff --git a/security/smack/Kconfig b/security/smack/Kconfig
index 271adae..002aa01 100644
--- a/security/smack/Kconfig
+++ b/security/smack/Kconfig
@@ -30,6 +30,17 @@ config SECURITY_SMACK_BRINGUP
permissive mode of other systems.
If you are unsure how to answer this question, answer N.
+config SECURITY_SMACK_AUTOLABEL
+ bool Enable Automatic Smack Labeling
+ depends on SECURITY_SMACK
+ default n
+ help
+ To remove out the gap between file creation and actual labeling,
+ this option gives the additional interface for automatic labeling.
+ With this option enabled, a file will posseses the assigned label
+ in autolabel table at creation.
+ If you are unsure how to answer this question, answer N.
+
config SECURITY_SMACK_NETFILTER
bool Packet marking using secmarks for netfilter
depends on SECURITY_SMACK
diff --git a/security/smack/smack.h b/security/smack/smack.h
index fff0c61..8b7ee83 100644
--- a/security/smack/smack.h
+++ b/security/smack/smack.h
@@ -24,6 +24,7 @@
#include linux/list.h
#include linux/rculist.h
#include linux/lsm_audit.h
+#include linux/namei.h
/*
* Use IPv6 port labeling if IPv6 is enabled and secmarks
@@ -106,6 +107,9 @@ struct inode_smack {
struct smack_known *smk_inode; /* label of the fso */
struct smack_known *smk_task; /* label of the task */
struct smack_known *smk_mmap; /* label of the mmap domain */
+#ifdef CONFIG_SECURITY_SMACK_AUTOLABEL
+ struct smack_auto_label *smk_auto;
+#endif
struct mutexsmk_lock; /* initialization lock */
int smk_flags; /* smack inode flags */
};
@@ -480,4 +484,23 @@ static inline void smk_ad_setfield_u_net_sk(struct
smk_audit_info *a,
}
#endif
+#ifdef CONFIG_SECURITY_SMACK_AUTOLABEL
+struct smack_auto_label {
+ bool disabled;
+ char *fpath;
+ struct list_head entry;
+ struct smack_known *label;
+ struct inode *inode;
+};
+
+extern struct list_head smack_autolabel_list;
+extern struct mutex smack_autolabel_lock;
+
+extern struct smack_known *smk_inode_bind_autolabel(struct inode *);
+extern void smk_inode_unbind_autolabel(struct inode *);
+#else
+#define smk_inode_bind_autolabel(inode) NULL
+#define smk_inode_unbind_autolabel(inode)do { } while (0)
+#endif /* CONFIG_SECURITY_SMACK_AUTOLABEL */
+
#endif /* _SECURITY_SMACK_H */
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 996c889..851e8b4 100644
---
