lkml.org 
[lkml]   [2012]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF
On Thu, Jan 12, 2012 at 3:05 PM, Eric Paris <eparis@redhat.com> wrote:
> On Thu, 2012-01-12 at 14:08 -0500, Kyle Moffett wrote:
>> On Thu, Jan 12, 2012 at 13:44, Andrew Lutomirski <luto@mit.edu> wrote:
>> > On Thu, Jan 12, 2012 at 10:32 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> >> You can do any amount of crazy things with selinux, but the other side
>> >> of the coin is that it would also be trivial to teach selinux about
>> >> this same "restricted environment" bit, and just say that a process
>> >> with that bit set doesn't get to match whatever selinux privilege
>> >> escalation rules..
>
>> I don't see any issues with SELinux support for this feature.
>>
>> Specifically, when you try to execute something in SELinux, it will
>> first look at the types and try to "execute" (involving a type
>> transition IE: security label change).
>>
>> But if that fails in many cases it may still be allowed to
>> "execute_no_trans" (IE: regular non-privileged exec() without a
>> transition).
>
> That's not true.  See specifically
> security/selinux/hooks.c::selinux_bprm_set_creds()  We calculate a label
> for the new task (that may or may not be the same) and then check if
> there is permission to run the new binary with the new label.  There is
> no fallback.
>
> The exception would be if the binary is on a MNT_NOSUID mount point, in
> which case we calculate the new label, then just revert to the same
> label.
>
> At first glance it looks to me like a reasonable way to implement this
> at first would be to do the new checks right next to any place we
> already do MNT_NOSUID checks and mimic their behavior.  If there are
> other priv escalation points in the kernel we might need to consider if
> MNT_NOSUID is adequate....
>

I don't really like the current logic. It does:

if (old_tsec->exec_sid) {
new_tsec->sid = old_tsec->exec_sid;
/* Reset exec SID on execve. */
new_tsec->exec_sid = 0;
} else {
/* Check for a default transition on this program. */
rc = security_transition_sid(old_tsec->sid, isec->sid,
SECCLASS_PROCESS, NULL,
&new_tsec->sid);
if (rc)
return rc;
}

COMMON_AUDIT_DATA_INIT(&ad, PATH);
ad.u.path = bprm->file->f_path;

if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)
new_tsec->sid = old_tsec->sid;

which means that, if MNT_NOSUD, then exec_sid is silently ignored.
I'd rather fail in that case, but it's probably too late for that.
However, if we set the "no new privileges" flag, then we could fail,
since there's no old ABI to be compatible with. I'll implement it
that way.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-01-13 00:37    [W:0.849 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site