[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 20 Aug 2018 19:30:57 +0000
From: "Schaufler, Casey" <casey.schaufler@...el.com>
To: Stephen Smalley <sds@...ho.nsa.gov>, "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>, "selinux@...ho.nsa.gov"
<selinux@...ho.nsa.gov>, "Hansen, Dave" <dave.hansen@...el.com>, "Dock,
Deneen T" <deneen.t.dock@...el.com>, "kristen@...ux.intel.com"
<kristen@...ux.intel.com>, "arjan@...ux.intel.com" <arjan@...ux.intel.com>
Subject: RE: [PATCH RFC v2 5/5] SELinux: Support SELinux determination of
side-channel vulnerability
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@...ho.nsa.gov]
> Sent: Monday, August 20, 2018 10:44 AM
> To: Schaufler, Casey <casey.schaufler@...el.com>; kernel-
> hardening@...ts.openwall.com; linux-kernel@...r.kernel.org; linux-security-
> module@...r.kernel.org; selinux@...ho.nsa.gov; Hansen, Dave
> <dave.hansen@...el.com>; Dock, Deneen T <deneen.t.dock@...el.com>;
> kristen@...ux.intel.com; arjan@...ux.intel.com
> Subject: Re: [PATCH RFC v2 5/5] SELinux: Support SELinux determination of
> side-channel vulnerability
>
> On 08/20/2018 12:59 PM, Schaufler, Casey wrote:
> >> -----Original Message-----
> >> From: Stephen Smalley [mailto:sds@...ho.nsa.gov]
> >> Sent: Monday, August 20, 2018 9:03 AM
> >> To: Schaufler, Casey <casey.schaufler@...el.com>; kernel-
> >> hardening@...ts.openwall.com; linux-kernel@...r.kernel.org; linux-security-
> >> module@...r.kernel.org; selinux@...ho.nsa.gov; Hansen, Dave
> >> <dave.hansen@...el.com>; Dock, Deneen T <deneen.t.dock@...el.com>;
> >> kristen@...ux.intel.com; arjan@...ux.intel.com
> >> Subject: Re: [PATCH RFC v2 5/5] SELinux: Support SELinux determination of
> >> side-channel vulnerability
> >>
> >> On 08/17/2018 06:16 PM, Casey Schaufler wrote:
> >>> SELinux considers tasks to be side-channel safe if they
> >>> have PROCESS_SHARE access.
> >>
> >> Now the description and the code no longer match.
> >
> > You're right.
> >
> >>>
> >>> Signed-off-by: Casey Schaufler <casey.schaufler@...el.com>
> >>> ---
> >>> security/selinux/hooks.c | 9 +++++++++
> >>> 1 file changed, 9 insertions(+)
> >>>
> >>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> >>> index a8bf324130f5..7fbd7d7ac1cb 100644
> >>> --- a/security/selinux/hooks.c
> >>> +++ b/security/selinux/hooks.c
> >>> @@ -4219,6 +4219,14 @@ static void selinux_task_to_inode(struct
> >> task_struct *p,
> >>> spin_unlock(&isec->lock);
> >>> }
> >>>
> >>> +static int selinux_task_safe_sidechannel(struct task_struct *p)
> >>> +{
> >>> + struct av_decision avd;
> >>> +
> >>> + return avc_has_perm_noaudit(&selinux_state, current_sid(),
> >> task_sid(p),
> >>> + SECCLASS_FILE, FILE__READ, 0, &avd);
> >>> +}
> >>
> >> And my question from before still stands: why do we need a new hook and
> >> new security module instead of just using ptrace_may_access()?
> >
> > Locking. The SELinux check, for example, will lock up solid while trying
> > to generate an audit record. There is no good reason aside from coding
> > convenience to assume that the same restrictions will apply for side-channel
> > as apply to ptrace. I'm actually a touch surprised you're not suggesting a
> > separate SECCLASS or access mode for the SELinux hook.
>
> The PTRACE_MODE_NOAUDIT flag to ptrace_may_access() would address the
> locking concern.
OK ...
> Duplicating the ptrace access checking logic seems
> prone to errors and inconsistencies.
That's true only if the ptrace logic and the safe-sidechannel logic
are identical. I don't believe that is a safe assumption. It would sure
be convenient. But I would hate to see a change made for either
ptrace or safe_sidechannel that interfered with the correct behavior
of the other.
> I can't imagine policy writers
> understanding what "safe sidechannel" means, much less deciding when to
> allow it.
I can't argue with that. But then, I have always had trouble with the
SELinux policy scheme.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
