Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

On Sat, May 14, 2011 at 2:30 AM, Ingo Molnar [off-list ref] wrote:

* Eric Paris [off-list ref] wrote:

quoted

[dropping microblaze and roland]

lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:

quoted

* James Morris [off-list ref] wrote:

quoted

It is a simple and sensible security feature, agreed? It allows most c=

ode to

quoted

quoted

run well and link to countless libraries - but no access to other file=

s is

quoted

quoted

allowed.

It's simple enough and sounds reasonable, but you can read all the discu=

ssion

quoted

about AppArmour why many people don't really think it's the best. [...]

I have to say most of the participants of the AppArmour flamefests were d=

ead

wrong, and it wasnt the AppArmour folks who were wrong ...

The straight ASCII VFS namespace *makes sense*, and yes, the raw physical
objects space that SELinux uses makes sense as well.

And no, i do not subscribe to the dogma that it is not possible to secure=

 the

ASCII VFS namespace: it evidently is possible, if you know and handle the
ambiguitites. It is also obviously true that the ASCII VFS namespaces we =

use

every day are a *lot* more intuitive than the labeled physical objects sp=

ace

...

What all the security flamewars missed is the simple fact that being intu=

itive

matters a *lot* not just to not annoy users, but also to broaden the effe=

ctive

number of security-conscious developers ...

quoted

quoted

Unfortunately this audit callback cannot be used for my purposes, beca=

use

quoted

quoted

the event is single-purpose for auditd and because it allows no feedba=

ck

quoted

quoted

(no deny/accept discretion for the security policy).

But if had this simple event there:

=A0 =A0 err =3D event_vfs_getname(result);

Wow it sounds so easy. =A0Now lets keep extending your train of thought
until we can actually provide the security provided by SELinux. =A0What =

do

quoted

we end up with? =A0We end up with an event hook right next to every LSM
hook. =A0You know, the LSM hooks were placed where they are for a reason=

.

quoted

Because those were the locations inside the kernel where you actually
have information about the task doing an operation and the objects
(files, sockets, directories, other tasks, etc) they are doing an
operation on.

Honestly all you are talking about it remaking the LSM with 2 sets of
hooks instead if 1. =A0Why? [...]

Not at all. I am taking about using *one* set of events, to keep the intr=

usion

at the lowest possible level.

LSM could make use of them as well.

Obviously for pragmatic reasons that might not be feasible initially.

quoted

[...] =A0It seems much easier that if you want the language of the filte=

r

quoted

engine you would just make a new LSM that uses the filter engine for it'=

s

quoted

policy language rather than the language created by SELinux or SMACK or =

name

quoted

your LSM implementation.

Correct, that is what i suggested.

Note that performance is a primary concern, so if certain filters are ver=

y

popular then in practice this would come with support for a couple of 'bu=

ilt

in' (pre-optimized) filters that the kernel can accelerate directly, so t=

hat we

do not incure the cost of executing the filter preds for really common-se=

nse

security policies that almost everyone is using.

I.e. in the end we'd *roughly* end up with the same performance and secur=

ity as

we are today (i mean, SELinux and the other LSMs did a nice job of collec=

ting

the things that apps should be careful about), but the crutial difference=

 isnt

just the advantages i menioned, but the fact that the *development model*=

 of

security modules would be a *lot* more extensible.

So security efforts could move to a whole different level: they could mov=

e into

key apps and they could integrate with the general mind-set of developers=

.

At least Will as an application framework developer cares, so that hope i=

s

justified i think.

quoted

quoted

=A0- unprivileged: =A0application-definable, allowing the embedding of=

 security

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 policy in *apps* as well, not just=

 the system

quoted

quoted

=A0- flexible: =A0 =A0 =A0can be added/removed runtime unprivileged, a=

nd cheaply so

quoted

quoted

=A0- transparent: =A0 does not impact executing code that meets the po=

licy

quoted

quoted

=A0- nestable: =A0 =A0 =A0it is inherited by child tasks and is fundam=

entally stackable,

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multiple policies will have the co=

mbined effect and they

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 are transparent to each other. So =

if a child task within a

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sandbox adds *more* checks then th=

ose add to the already

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 existing set of checks. We only na=

rrow permissions, never

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extend them.

=A0- generic: =A0 =A0 =A0 allowing observation and (safe) control of s=

ecurity relevant

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters not just at the system =

call boundary but at other

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 relevant places of kernel executio=

n as well: which

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 points/callbacks could also be use=

d for other types of event

quoted

quoted

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extraction such as perf. It could =

even be shared with audit ...

quoted

I'm not arguing that any of these things are bad things. =A0What you des=

cribe

quoted

is a new LSM that uses a discretionary access control model but with the
granularity and flexibility that has traditionally only existed in the
mandatory access control security modules previously implemented in the
kernel.

I won't argue that's a bad idea, there's no reason in my mind that a pro=

cess

quoted

shouldn't be allowed to control it's own access decisions in a more flex=

ible

quoted

way than rwx bits. =A0Then again, I certainly don't see a reason that th=

is

quoted

syscall hardening patch should be held up while a whole new concept in
computer security is contemplated...

Note, i'm not actually asking for the moon, a pony and more.

I fully submit that we are yet far away from being able to do a full LSM =

via

this mechanism.

What i'm asking for is that because the syscall point steps taken by Will=

 look

very promising so it would be nice to do *that* in a slightly more flexib=

le

scheme that does not condemn it to be limited to the syscall boundary and=

 such

...

What do you suggest here?

From my brief exploration of the ftrace/perf (and seccomp) code, I

don't see a clean way of integrating over the existing interfaces to
the ftrace framework (e.g., the global perf event pump seems to be a
mismatch), but I may be missing something obvious.   In my view,
implementing this nestled between the seccomp/ftrace world provides a
stepping stone forward without being too restrictive.  No matter how
we change security events in the future, system calls will always be
the first line of attack surface reduction.  It could just mean that,
in the long term, accessing the "security event filtering" framework
is done through another new interface with seccomp providing only a
targeted syscall filtering featureset that may one day be deprecated
(if that day ever comes).

If there's a clear way to cleanly expand this interface that I'm
missing, I'd love to know - thanks!
will

Also, to answer you, do you say that by my argument someone should have s=

tood

up and said 'no' to the LSM mess that was introduced a couple of years ag=

o and

which caused so many problems:

=A0- kernel inefficiencies and user-space overhead

=A0- stalled security efforts

=A0- infighting

=A0- friction, fragmentation, overmodularization

=A0- non-stackability

=A0- security annoyances on the Linux desktop

=A0- probably *less* Linux security

and should have asked them to do something better designed instead?

Thanks,

=A0 =A0 =A0 =A0Ingo