linux-kernel - Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAObL_7HbL-+613aALTb2g1RSaYqhZ6tAX-Oaj5Dhw9eZry=mew@mail.gmail.com>
Date:	Thu, 12 Jan 2012 15:33:47 -0800
From:	Andrew Lutomirski <luto@....edu>
To:	Eric Paris <eparis@...hat.com>
Cc:	Kyle Moffett <kyle@...fetthome.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org,
	keescook@...omium.org, john.johansen@...onical.com,
	serge.hallyn@...onical.com, coreyb@...ux.vnet.ibm.com,
	pmoore@...hat.com, djm@...drot.org, segoon@...nwall.com,
	jmorris@...ei.org, scarybeasts@...il.com, avi@...hat.com,
	penberg@...helsinki.fi, viro@...iv.linux.org.uk, mingo@...e.hu,
	akpm@...ux-foundation.org, khilman@...com, borislav.petkov@....com,
	amwang@...hat.com, oleg@...hat.com, ak@...ux.intel.com,
	eric.dumazet@...il.com, gregkh@...e.de, dhowells@...hat.com,
	daniel.lezcano@...e.fr, linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, olofj@...omium.org,
	mhalcrow@...gle.com, dlaor@...hat.com
Subject: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF

On Thu, Jan 12, 2012 at 3:05 PM, Eric Paris <eparis@...hat.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@....edu> wrote:
>> > On Thu, Jan 12, 2012 at 10:32 AM, Linus Torvalds <torvalds@...ux-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/