2010-02-26 10:39:02

by domg472

[permalink] [raw]
Subject: [refpolicy] [ devices patch 1/1] Fix dev_list_sysfs interface to allow domains to read sysfs lnk_file.

Signed-off-by: Dominick Grift <[email protected]>
---
:100644 100644 fe31e1f... 83c4a2a... M policy/modules/kernel/devices.if
policy/modules/kernel/devices.if | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/policy/modules/kernel/devices.if b/policy/modules/kernel/devices.if
index fe31e1f..83c4a2a 100644
--- a/policy/modules/kernel/devices.if
+++ b/policy/modules/kernel/devices.if
@@ -3322,6 +3322,7 @@ interface(`dev_list_sysfs',`
')

list_dirs_pattern($1, sysfs_t, sysfs_t)
+ allow $1 sysfs_t:lnk_file read_lnk_file_perms;
')

########################################
--
1.6.6.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100226/f2452777/attachment.bin


2010-03-04 15:53:24

by cpebenito

[permalink] [raw]
Subject: [refpolicy] [ devices patch 1/1] Fix dev_list_sysfs interface to allow domains to read sysfs lnk_file.

On Fri, 2010-02-26 at 11:39 +0100, Dominick Grift wrote:
> Signed-off-by: Dominick Grift <[email protected]>

I'm on the fence for this one. Normally I think this is better suited
for dev_read_sysfs(), which has this perm already. But since sysfs is
so highly linked, I suppose it could make sense. What prompted this?

> ---
> :100644 100644 fe31e1f... 83c4a2a... M policy/modules/kernel/devices.if
> policy/modules/kernel/devices.if | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/kernel/devices.if b/policy/modules/kernel/devices.if
> index fe31e1f..83c4a2a 100644
> --- a/policy/modules/kernel/devices.if
> +++ b/policy/modules/kernel/devices.if
> @@ -3322,6 +3322,7 @@ interface(`dev_list_sysfs',`
> ')
>
> list_dirs_pattern($1, sysfs_t, sysfs_t)
> + allow $1 sysfs_t:lnk_file read_lnk_file_perms;
> ')
>
> ########################################
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

2010-03-04 17:27:14

by domg472

[permalink] [raw]
Subject: [refpolicy] [ devices patch 1/1] Fix dev_list_sysfs interface to allow domains to read sysfs lnk_file.

On 03/04/2010 04:53 PM, Christopher J. PeBenito wrote:
> On Fri, 2010-02-26 at 11:39 +0100, Dominick Grift wrote:
>> Signed-off-by: Dominick Grift <[email protected]>
>
> I'm on the fence for this one. Normally I think this is better suited
> for dev_read_sysfs(), which has this perm already. But since sysfs is
> so highly linked, I suppose it could make sense. What prompted this?

Well i needed an interface that does not provide access to read files
but does provides access to read lnk_files (for listing sysfs).

I needed it for my kismet policy:

> dev_list_sysfs(kismet_servers)
> allow kismet_servers sysfs_t:lnk_file read;

>> ---
>> :100644 100644 fe31e1f... 83c4a2a... M policy/modules/kernel/devices.if
>> policy/modules/kernel/devices.if | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/policy/modules/kernel/devices.if b/policy/modules/kernel/devices.if
>> index fe31e1f..83c4a2a 100644
>> --- a/policy/modules/kernel/devices.if
>> +++ b/policy/modules/kernel/devices.if
>> @@ -3322,6 +3322,7 @@ interface(`dev_list_sysfs',`
>> ')
>>
>> list_dirs_pattern($1, sysfs_t, sysfs_t)
>> + allow $1 sysfs_t:lnk_file read_lnk_file_perms;
>> ')
>>
>> ########################################
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100304/3a3fa11e/attachment.bin