lkml.org 
[lkml]   [2020]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] selinux: allow kernfs symlinks to inherit parent directory context
From
Date
On 1/24/20 2:08 PM, Christian Göttsche wrote:
> Am Fr., 24. Jan. 2020 um 19:53 Uhr schrieb Stephen Smalley <sds@tycho.nsa.gov>:
>>
>> On 1/24/20 1:42 PM, Christian Göttsche wrote:
>>> Currently symlinks on kernel filesystems, like sysfs, are labeled on
>>> creation with the parent fs root sid.
>>>
>>> Allow symlinks to inherit the parent directory context, so fine-grained
>>> kernfs labeling can be applied to symlinks too and checking contexts
>>> doesn't complain about them.
>>>
>>> For backward-compatibility this behavior is contained in a new policy
>>> capability: kernfs_sovereign_symlinks
>>>
>>> Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
>>> ---

>> Not fond of the name. 1) kernfs is a kernel implementation detail,
>> shouldn't be exposed to policy; genfs is the policy construct 2)
>> sovereign doesn't seem to fit the meaning of this capability; seclabel
>> would be more appropriate.
>
> Something like genfs_seclabel_symlinks?

Works for me.

>
>>> + (sbsec->flags & SE_SBGENFS_XATTR))) {
>>
>> Why limit this to SE_SBGENFS_XATTR filesystems? Why not just make the test:
>> if ((sbsec->flags & SE_SBGENFS) && (!S_ISLNK(inode->i_mode) ||
>> selinux_policycap_genfs_symlinkseclabel()))
>> or similar.
>
> I somehow thought that this functionality is limited to filesystems
> with SE_SBGENFS_XATTR;
> so I can expand the check to SE_SBGENFS.

I could be wrong but I don't see why it would need to be limited in that
way.

\
 
 \ /
  Last update: 2020-01-24 20:18    [W:0.036 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site