Re: lnk_file read permission

On Wed, Jul 29, 2020 at 11:23 PM Gionatan Danti <[email protected]> wrote:
> Il 2020-05-05 10:43 Gionatan Danti ha scritto:
> > So I was wondering why each symlink type is specifically allowed
> > rather than giving any processes a generic access to symlinks. Is this
> > kind of rule not permitted by selinux? Can it open the door to other
> > attacks? If so, why?

There are attacks possible, although possibly not for the threat model
that is interesting for a regular Fedora user. A symlink is
technically still a file with some data in it (representing the path
to the target, but you can basically put an arbitrary string there),
so it could be used as a covert channel to smuggle some data between
domains. In an MLS setting, which is one of the main target use cases
of SELinux, such information leak could be a serious concern.

So for Fedora it might indeed make sense to add some
"domain_can_read_symlinks" boolean for people who customize things
with symlinks a lot... But there might be other reasons for being
careful with symlinks that you or I haven't thought of :) I'd suggest
asking on the upstream mailing list ([email protected]) on
if/why it's a good idea to follow the principle of least privilege
also for symlinks. You are likely to get a more educated answer there.

> On one of the bugzilla issue I opened regarding various processes
> lacking lnk_read permission, one reply stated that denying lnk_read
> permission lead to "unnecessary fragility". Is that true?

I don't understand what is meant here... Do you have a link to the
bugzilla in question?

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
_______________________________________________
selinux mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[email protected]