linux-kernel - Re: [PATCH] selinux: allow kernfs symlinks to inherit parent directory context

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <259f3abe-5d15-ea8d-98b6-765f1e5959dd@tycho.nsa.gov>
Date:   Fri, 24 Jan 2020 14:18:25 -0500
From:   Stephen Smalley <sds@...ho.nsa.gov>
To:     Christian Göttsche <cgzones@...glemail.com>
Cc:     Paul Moore <paul@...l-moore.com>,
        Eric Paris <eparis@...isplace.org>,
        Ondrej Mosnacek <omosnace@...hat.com>, selinux@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selinux: allow kernfs symlinks to inherit parent
 directory context

On 1/24/20 2:08 PM, Christian Göttsche wrote:
> Am Fr., 24. Jan. 2020 um 19:53 Uhr schrieb Stephen Smalley <sds@...ho.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@...glemail.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.