From: Gionatan Danti <g.danti@assyoma.it>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: lnk_file read permission
Date: Fri, 31 Jul 2020 18:56:09 +0200 [thread overview]
Message-ID: <e0c9fd0926d97314b4abec38ab0fe8ca@assyoma.it> (raw)
In-Reply-To: <CAEjxPJ5XGhaZmAvC=-2A=KaCKmqZEp4r6z7fOoDP0+GpJDOZog@mail.gmail.com>
Il 2020-07-31 15:12 Stephen Smalley ha scritto:
> The lnk_file read permission check can be used to protect processes
> from following/reading untrusted symlinks, often used in malicious
> symlink attacks.
> The more broadly you allow it, the more potential for the process to
> be misdirected to an unexpected file in order to overwrite some file
> or leak its contents.
Hi Stephen,
I generally know the catchs with symlinks, but I fail to understand how
this can be a problem for selinux: after all, the real/target file must
be labeled with the correct type, otherwise the service binary (running
in its confined domain) will not be able to open it. In other words, it
is my understanding that selinux not only matches the symlink, but the
target file also. So it should not be possible to fool it by chaning the
symlink target on the fly. Am I missing something?
> That said, I think the policy macros/interfaces could allow it more
> widely than is currently done without too much risk. That's more of a
> question for selinux-refpolicy for upstream policy and/or the Fedora
> selinux list for their fork of it. The alternative approach for
> relocating directories is to use bind mounts.
Well, I'm coming from the fedora selinux mailing list ;)
But if you think I should write to selinux-refpolicy, I will do that.
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8
next prev parent reply other threads:[~2020-07-31 16:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 9:57 lnk_file read permission Gionatan Danti
2020-07-31 13:12 ` Stephen Smalley
2020-07-31 16:56 ` Gionatan Danti [this message]
2020-07-31 16:25 ` Christian Göttsche
2020-07-31 16:53 ` Dominick Grift
2020-07-31 17:09 ` Gionatan Danti
2020-07-31 19:37 ` Gionatan Danti
2020-07-31 19:44 ` Dominick Grift
2020-07-31 19:49 ` Gionatan Danti
2020-07-31 17:00 ` Gionatan Danti
2020-07-31 17:45 ` Dominick Grift
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e0c9fd0926d97314b4abec38ab0fe8ca@assyoma.it \
--to=g.danti@assyoma.it \
--cc=selinux@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.