* linux kernel reference to non-existent CONFIG_FSL_85XX_CACHE_SRAM
From: Robert P. J. Day @ 2011-05-14 23:04 UTC (permalink / raw)
To: linuxppc-dev
the current kernel source tree contains a Makefile reference to the
above Kconfig variable that doesn't appear to be defined anywhere.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Will Drewry @ 2011-05-14 20:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Ralf Baechle, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, jmorris, Ingo Molnar, Roland McGrath,
Ingo Molnar, Serge E. Hallyn, Peter Zijlstra, microblaze-uclinux,
Steven Rostedt, Tejun Heo, Thomas Gleixner, kees.cook,
linux-arm-kernel, Michal Marek, Michal Simek, agl, linux-kernel,
Eric Paris, Paul Mundt, Martin Schwidefsky, linux390,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <201105132135.34741.arnd@arndb.de>
On Fri, May 13, 2011 at 2:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 12 May 2011, Will Drewry wrote:
>> This change adds a new seccomp mode based on the work by
>> agl@chromium.org in [1]. This new mode, "filter mode", provides a hash
>> table of seccomp_filter objects. =A0When in the new mode (2), all system
>> calls are checked against the filters - first by system call number,
>> then by a filter string. =A0If an entry exists for a given system call a=
nd
>> all filter predicates evaluate to true, then the task may proceed.
>> Otherwise, the task is killed (as per seccomp_mode =3D=3D 1).
>
> I've got a question about this: Do you expect the typical usage to disall=
ow
> ioctl()? Given that ioctl alone is responsible for a huge number of explo=
its
> in various drivers, while certain ioctls are immensely useful (FIONREAD,
> FIOASYNC, ...), do you expect to extend the mechanism to filter specific
> ioctl commands in the future?
In many cases, I do expect ioctl's to be dropped, but it's totally up
to whoever is setting the filters.
As is, it can already help out: [even though an LSM, if available,
would be appropriate to define a fine-grained policy]
ioctl() is hooked by the ftrace syscalls infrastructure (via SYSCALL_DEFINE=
3):
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned
long, arg)
This means you can do:
sprintf(filter, "cmd =3D=3D %u || cmd =3D=3D %u", FIOASYNC, FIONREAD);
prctl(PR_SET_SECCOMP_FILTER, __NR_ioctl, filter);
...
prctl(PR_SET_SECCOMP, 2, 0);
and then you'll be able to call ioctl on any fd with any argument but
limited to only the FIOASYNC and FIONREAD commands.
Depending on integration, it could even be limited to ioctl commands
that are appropriate to a known fd if the fd is opened prior to
entering seccomp mode 2. Alternatively, __NR__ioctl could be allowed
with a filter of "1" then narrowed through a later addition of
something like "(fd =3D=3D %u && (cmd =3D=3D %u || cmd =3D=3D %u))" or some=
thing
along those lines.
Does that make sense?
In general, this interface won't need specific extensions for most
system call oriented filtering events. ftrace events may be expanded
(to include more system calls), but that's behind the scenes. Only
arguments subject to time-of-check-time-of-use attacks (data living in
userspace passed in by pointer) are not safe to use via this
interface. In theory, that limitation could also be lifted in the
implementation without changing the ABI.
Thanks!
will
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Will Drewry @ 2011-05-14 20:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Eric Paris, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, James Morris, Linus Torvalds, Ingo Molnar,
kees.cook, Serge E. Hallyn, Peter Zijlstra, Steven Rostedt,
Tejun Heo, Thomas Gleixner, linux-arm-kernel, Michal Marek,
Michal Simek, linuxppc-dev, linux-kernel, Ralf Baechle,
Paul Mundt, Martin Schwidefsky, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <20110514073015.GB9307@elte.hu>
On Sat, May 14, 2011 at 2:30 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Eric Paris <eparis@redhat.com> wrote:
>
>> [dropping microblaze and roland]
>>
>> lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
>> > * James Morris <jmorris@namei.org> wrote:
>>
>> > It is a simple and sensible security feature, agreed? It allows most c=
ode to
>> > run well and link to countless libraries - but no access to other file=
s is
>> > allowed.
>>
>> It's simple enough and sounds reasonable, but you can read all the discu=
ssion
>> 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 ...
>
>> > Unfortunately this audit callback cannot be used for my purposes, beca=
use
>> > the event is single-purpose for auditd and because it allows no feedba=
ck
>> > (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
>> 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=
.
>> 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.
>
>> [...] =A0It seems much easier that if you want the language of the filte=
r
>> engine you would just make a new LSM that uses the filter engine for it'=
s
>> policy language rather than the language created by SELinux or SMACK or =
name
>> 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.
>
>> > =A0- unprivileged: =A0application-definable, allowing the embedding of=
security
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 policy in *apps* as well, not just=
the system
>> >
>> > =A0- flexible: =A0 =A0 =A0can be added/removed runtime unprivileged, a=
nd cheaply so
>> >
>> > =A0- transparent: =A0 does not impact executing code that meets the po=
licy
>> >
>> > =A0- nestable: =A0 =A0 =A0it is inherited by child tasks and is fundam=
entally stackable,
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multiple policies will have the co=
mbined effect and they
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 are transparent to each other. So =
if a child task within a
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sandbox adds *more* checks then th=
ose add to the already
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 existing set of checks. We only na=
rrow permissions, never
>> > =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
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters not just at the system =
call boundary but at other
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 relevant places of kernel executio=
n as well: which
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 points/callbacks could also be use=
d for other types of event
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extraction such as perf. It could =
even be shared with audit ...
>>
>> I'm not arguing that any of these things are bad things. =A0What you des=
cribe
>> 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
>> shouldn't be allowed to control it's own access decisions in a more flex=
ible
>> way than rwx bits. =A0Then again, I certainly don't see a reason that th=
is
>> 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
>
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Arnd Bergmann @ 2011-05-13 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Ralf Baechle, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, jmorris, Ingo Molnar, Ingo Molnar,
Serge E. Hallyn, Peter Zijlstra, microblaze-uclinux,
Steven Rostedt, Tejun Heo, Thomas Gleixner, kees.cook,
Roland McGrath, Michal Marek, Michal Simek, Will Drewry, agl,
linux-kernel, Eric Paris, Paul Mundt, Martin Schwidefsky,
linux390, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1305169376-2363-1-git-send-email-wad@chromium.org>
On Thursday 12 May 2011, Will Drewry wrote:
> This change adds a new seccomp mode based on the work by
> agl@chromium.org in [1]. This new mode, "filter mode", provides a hash
> table of seccomp_filter objects. When in the new mode (2), all system
> calls are checked against the filters - first by system call number,
> then by a filter string. If an entry exists for a given system call and
> all filter predicates evaluate to true, then the task may proceed.
> Otherwise, the task is killed (as per seccomp_mode == 1).
I've got a question about this: Do you expect the typical usage to disallow
ioctl()? Given that ioctl alone is responsible for a huge number of exploits
in various drivers, while certain ioctls are immensely useful (FIONREAD,
FIOASYNC, ...), do you expect to extend the mechanism to filter specific
ioctl commands in the future?
Arnd
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-14 7:30 UTC (permalink / raw)
To: Eric Paris
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Peter Zijlstra, Steven Rostedt, Tejun Heo,
Thomas Gleixner, linux-arm-kernel, Michal Marek, Michal Simek,
Will Drewry, linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <1305299455.2076.26.camel@localhost.localdomain>
* Eric Paris <eparis@redhat.com> wrote:
> [dropping microblaze and roland]
>
> lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
> > * James Morris <jmorris@namei.org> wrote:
>
> > It is a simple and sensible security feature, agreed? It allows most code to
> > run well and link to countless libraries - but no access to other files is
> > allowed.
>
> It's simple enough and sounds reasonable, but you can read all the discussion
> 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 dead
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 space
...
What all the security flamewars missed is the simple fact that being intuitive
matters a *lot* not just to not annoy users, but also to broaden the effective
number of security-conscious developers ...
> > Unfortunately this audit callback cannot be used for my purposes, because
> > the event is single-purpose for auditd and because it allows no feedback
> > (no deny/accept discretion for the security policy).
> >
> > But if had this simple event there:
> >
> > err = event_vfs_getname(result);
>
> Wow it sounds so easy. Now lets keep extending your train of thought
> until we can actually provide the security provided by SELinux. What do
> we end up with? We end up with an event hook right next to every LSM
> hook. You know, the LSM hooks were placed where they are for a reason.
> 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. Why? [...]
Not at all. I am taking about using *one* set of events, to keep the intrusion
at the lowest possible level.
LSM could make use of them as well.
Obviously for pragmatic reasons that might not be feasible initially.
> [...] It seems much easier that if you want the language of the filter
> engine you would just make a new LSM that uses the filter engine for it's
> policy language rather than the language created by SELinux or SMACK or name
> your LSM implementation.
Correct, that is what i suggested.
Note that performance is a primary concern, so if certain filters are very
popular then in practice this would come with support for a couple of 'built
in' (pre-optimized) filters that the kernel can accelerate directly, so that we
do not incure the cost of executing the filter preds for really common-sense
security policies that almost everyone is using.
I.e. in the end we'd *roughly* end up with the same performance and security as
we are today (i mean, SELinux and the other LSMs did a nice job of collecting
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 move 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 is
justified i think.
> > - unprivileged: application-definable, allowing the embedding of security
> > policy in *apps* as well, not just the system
> >
> > - flexible: can be added/removed runtime unprivileged, and cheaply so
> >
> > - transparent: does not impact executing code that meets the policy
> >
> > - nestable: it is inherited by child tasks and is fundamentally stackable,
> > multiple policies will have the combined effect and they
> > are transparent to each other. So if a child task within a
> > sandbox adds *more* checks then those add to the already
> > existing set of checks. We only narrow permissions, never
> > extend them.
> >
> > - generic: allowing observation and (safe) control of security relevant
> > parameters not just at the system call boundary but at other
> > relevant places of kernel execution as well: which
> > points/callbacks could also be used for other types of event
> > extraction such as perf. It could even be shared with audit ...
>
> I'm not arguing that any of these things are bad things. What you describe
> 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 process
> shouldn't be allowed to control it's own access decisions in a more flexible
> way than rwx bits. Then again, I certainly don't see a reason that this
> 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 flexible
scheme that does not condemn it to be limited to the syscall boundary and such
...
Also, to answer you, do you say that by my argument someone should have stood
up and said 'no' to the LSM mess that was introduced a couple of years ago and
which caused so many problems:
- kernel inefficiencies and user-space overhead
- stalled security efforts
- infighting
- friction, fragmentation, overmodularization
- non-stackability
- security annoyances on the Linux desktop
- probably *less* Linux security
and should have asked them to do something better designed instead?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-14 7:05 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Steven Rostedt, Tejun Heo, Thomas Gleixner,
linux-arm-kernel, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <1305300443.2466.77.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2011-05-13 at 16:57 +0200, Ingo Molnar wrote:
> > this is a security mechanism
>
> Who says? [...]
Kernel developers/maintainers of the affected code.
We have security hooks all around the kernel, which can deny/accept execution
at various key points, but we do not have 'execute arbitrary user-space defined
(safe) scripts' callbacks in general.
But yes, if a particular callback point is defined widely enough to allow much
bigger intervention into the flow of execution, then more is possible as well.
> [...] and why would you want to unify two separate concepts only to them
> limit it to security that just doesn't make sense.
I don't limit them to security - the callbacks themselves are either for
passive observation or, at most, for security accept/deny callbacks.
It's decided by the subsystem maintainers what kind of user-space control power
(or observation power) they want to allow, not me.
I would just like to not stop the facility itself at the 'observe only' level,
like you suggest.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Will Drewry @ 2011-05-13 16:29 UTC (permalink / raw)
To: Eric Paris
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, Ingo Molnar,
Serge E. Hallyn, Steven Rostedt, Tejun Heo, Thomas Gleixner,
kees.cook, linux-arm-kernel, Michal Marek, Michal Simek,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <1305302141.2076.56.camel@localhost.localdomain>
On Fri, May 13, 2011 at 10:55 AM, Eric Paris <eparis@redhat.com> wrote:
> On Fri, 2011-05-13 at 17:23 +0200, Peter Zijlstra wrote:
>> On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote:
>> > Then again, I certainly don't see a
>> > reason that this syscall hardening patch should be held up while a who=
le
>> > new concept in computer security is contemplated...
>>
>> Which makes me wonder why this syscall hardening stuff is done outside
>> of LSM? Why isn't is part of the LSM so that say SELinux can have a
>> syscall bitmask per security context?
>
> I could do that, but I like Will's approach better. =A0From the PoV of
> meeting security goals of information flow, data confidentiality,
> integrity, least priv, etc limiting on the syscall boundary doesn't make
> a lot of sense. =A0You just don't know enough there to enforce these
> things. =A0These are the types of goals that SELinux and other LSMs have
> previously tried to enforce. =A0From the PoV of making the kernel more
> resistant to attacks and making a process more resistant to misbehavior
> I think that the syscall boundary is appropriate. =A0Although I could do
> it in SELinux it don't really want to do it there.
There's also the problem that there are no hooks per-system call for
LSMs, only logical hooks that sometimes mirror system call names and
are called after user data has been parsed. If system call enter
hooks, like seccomp's, were added for LSMs, it would allow the lsm
bitmask approach, but it still wouldn't satisfy the issues you raise
below (and I wholeheartedly agree with).
> In case people are interested or confused let me give my definition of
> two words I've used a bit in these conversations: discretionary and
> mandatory. =A0Any time I talk about a 'discretionary' security decision i=
t
> is a security decisions that a process imposed upon itself. =A0Aka the
> choice to use seccomp is discretionary. =A0The choice to mark our own fil=
e
> u-wx is discretionary. =A0This isn't the best definition but it's one tha=
t
> works well in this discussion. =A0Mandatory security is one enforce by a
> global policy. =A0It's what selinux is all about. =A0SELinux doesn't give
> hoot what a process wants to do, it enforces a global policy from the
> top down. =A0You take over a process, well, too bad, you still have no
> choice but to follow the mandatory policy.
>
> The LSM does NOT enforce a mandatory access control model, it's just how
> it's been used in the past. =A0Ingo appears to me (please correct me if
> I'm wrong) to really be a fan of exposing the flexibility of the LSM to
> a discretionary access control model. =A0That doesn't seem like a bad
> idea. =A0And maybe using the filter engine to define the language to do
> this isn't a bad idea either. =A0But I think that's a 'down the road'
> project, not something to hold up a better seccomp.
>
>> Making it part of the LSM also avoids having to add this prctl().
>
> Well, it would mean exposing some new language construct to every LSM
> (instead of a single prctl construct) and it would mean anyone wanting
> to use the interface would have to rely on the LSM implementing those
> hooks the way they need it. =A0Honestly chrome can already get all of the
> benefits of this patch (given a perfectly coded kernel) and a whole lot
> more using SELinux, but (surprise surprise) not everyone uses SELinux.
> I think it's a good idea to expose a simple interface which will be
> widely enough adopted that many userspace applications can rely on it
> for hardening.
>
> The existence of the LSM and the fact that there exists multiple
> security modules that may or may not be enabled really leads application
> developers to be unable to rely on LSM for security. =A0If linux had a
> single security model which everyone could rely on we wouldn't really
> have as big of an issue but that's not possible. =A0So I'm advocating for
> this series which will provide a single useful change which applications
> can rely upon across distros and platforms to enhance the properties and
> abilities of the linux kernel.
>
> -Eric
>
>
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Eric Paris @ 2011-05-13 15:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, H. Peter Anvin,
sparclinux, Jiri Slaby, linux-s390, Russell King, x86,
James Morris, Linus Torvalds, Ingo Molnar, Ingo Molnar,
Serge E. Hallyn, Steven Rostedt, Tejun Heo, Thomas Gleixner,
kees.cook, linux-arm-kernel, Michal Marek, Michal Simek,
Will Drewry, linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <1305300181.2466.72.camel@twins>
On Fri, 2011-05-13 at 17:23 +0200, Peter Zijlstra wrote:
> On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote:
> > Then again, I certainly don't see a
> > reason that this syscall hardening patch should be held up while a whole
> > new concept in computer security is contemplated...
>
> Which makes me wonder why this syscall hardening stuff is done outside
> of LSM? Why isn't is part of the LSM so that say SELinux can have a
> syscall bitmask per security context?
I could do that, but I like Will's approach better. From the PoV of
meeting security goals of information flow, data confidentiality,
integrity, least priv, etc limiting on the syscall boundary doesn't make
a lot of sense. You just don't know enough there to enforce these
things. These are the types of goals that SELinux and other LSMs have
previously tried to enforce. From the PoV of making the kernel more
resistant to attacks and making a process more resistant to misbehavior
I think that the syscall boundary is appropriate. Although I could do
it in SELinux it don't really want to do it there.
In case people are interested or confused let me give my definition of
two words I've used a bit in these conversations: discretionary and
mandatory. Any time I talk about a 'discretionary' security decision it
is a security decisions that a process imposed upon itself. Aka the
choice to use seccomp is discretionary. The choice to mark our own file
u-wx is discretionary. This isn't the best definition but it's one that
works well in this discussion. Mandatory security is one enforce by a
global policy. It's what selinux is all about. SELinux doesn't give
hoot what a process wants to do, it enforces a global policy from the
top down. You take over a process, well, too bad, you still have no
choice but to follow the mandatory policy.
The LSM does NOT enforce a mandatory access control model, it's just how
it's been used in the past. Ingo appears to me (please correct me if
I'm wrong) to really be a fan of exposing the flexibility of the LSM to
a discretionary access control model. That doesn't seem like a bad
idea. And maybe using the filter engine to define the language to do
this isn't a bad idea either. But I think that's a 'down the road'
project, not something to hold up a better seccomp.
> Making it part of the LSM also avoids having to add this prctl().
Well, it would mean exposing some new language construct to every LSM
(instead of a single prctl construct) and it would mean anyone wanting
to use the interface would have to rely on the LSM implementing those
hooks the way they need it. Honestly chrome can already get all of the
benefits of this patch (given a perfectly coded kernel) and a whole lot
more using SELinux, but (surprise surprise) not everyone uses SELinux.
I think it's a good idea to expose a simple interface which will be
widely enough adopted that many userspace applications can rely on it
for hardening.
The existence of the LSM and the fact that there exists multiple
security modules that may or may not be enabled really leads application
developers to be unable to rely on LSM for security. If linux had a
single security model which everyone could rely on we wouldn't really
have as big of an issue but that's not possible. So I'm advocating for
this series which will provide a single useful change which applications
can rely upon across distros and platforms to enhance the properties and
abilities of the linux kernel.
-Eric
^ permalink raw reply
* RE: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system callfiltering
From: David Laight @ 2011-05-13 15:29 UTC (permalink / raw)
To: Eric Paris, Ingo Molnar
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, linux-kernel, David Howells, Paul Mackerras,
H. PeterAnvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Ingo Molnar, kees.cook, Serge E. Hallyn,
Steven Rostedt, Martin Schwidefsky, Thomas Gleixner, agl,
linux-arm-kernel, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, Oleg Nesterov, Ralf Baechle, Paul Mundt, Tejun Heo,
linux390, Andrew Morton, Linus Torvalds, David S. Miller
In-Reply-To: <1305299880.2076.31.camel@localhost.localdomain>
> ... If you can be completely stateless its easier, but there's
> a reason that stacking security modules is hard. Serge has tried in
the
> past and both dhowells and casey schaufler are working on it right
now.
> Stacking is never as easy as it sounds :)
For a bad example of trying to allow alternate security models
look at NetBSD's kauth code :-)
NetBSD also had issues where some 'system call trace' code
was being used to (try to) apply security - unfortunately
it worked by looking at the user-space buffers on system
call entry - and a multithreaded program can easily arrange
to update them after the initial check!
For trace/event type activities this wouldn't really matter,
for security policy it does.
(I've not looked directly at these event points in linux)
David
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-13 15:27 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Steven Rostedt, Tejun Heo, Thomas Gleixner,
linux-arm-kernel, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110513145737.GC32688@elte.hu>
On Fri, 2011-05-13 at 16:57 +0200, Ingo Molnar wrote:
> this is a security mechanism
Who says? and why would you want to unify two separate concepts only to
them limit it to security that just doesn't make sense.
Either you provide a full on replacement for notifier chain like things
or you don't, only extending trace events in this fashion for security
is like way weird.
Plus see the arguments Eric made about stacking stuff, not only security
schemes will have those problems.
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-13 15:23 UTC (permalink / raw)
To: Eric Paris
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, H. Peter Anvin,
sparclinux, Jiri Slaby, linux-s390, Russell King, x86,
James Morris, Linus Torvalds, Ingo Molnar, Ingo Molnar,
Serge E. Hallyn, Steven Rostedt, Tejun Heo, Thomas Gleixner,
kees.cook, linux-arm-kernel, Michal Marek, Michal Simek,
Will Drewry, linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <1305299455.2076.26.camel@localhost.localdomain>
On Fri, 2011-05-13 at 11:10 -0400, Eric Paris wrote:
> Then again, I certainly don't see a
> reason that this syscall hardening patch should be held up while a whole
> new concept in computer security is contemplated...=20
Which makes me wonder why this syscall hardening stuff is done outside
of LSM? Why isn't is part of the LSM so that say SELinux can have a
syscall bitmask per security context?
Making it part of the LSM also avoids having to add this prctl().
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Eric Paris @ 2011-05-13 15:17 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Steven Rostedt, Tejun Heo, Thomas Gleixner,
linux-arm-kernel, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110513131800.GA7883@elte.hu>
[dropping microblaze and roland]
On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
> > > I think the sanest semantics is to run all active callbacks as well.
> > >
> > > For example if this is used for three stacked security policies - as if 3 LSM
> > > modules were stacked at once. We'd call all three, and we'd determine that at
> > > least one failed - and we'd return a failure.
> >
> > But that only works for boolean functions where you can return the
> > multi-bit-or of the result. What if you need to return the specific
> > error code.
>
> Do you mean that one filter returns -EINVAL while the other -EACCES?
>
> Seems like a non-problem to me, we'd return the first nonzero value.
Sounds so easy! Why haven't LSMs stacked already? Because what happens
if one of these hooks did something stateful? Lets say on open, hook #1
returns EPERM. hook #2 allocates memory. The open is going to fail and
hooks #2 is never going to get the close() which should have freed the
allocation. If you can be completely stateless its easier, but there's
a reason that stacking security modules is hard. Serge has tried in the
past and both dhowells and casey schaufler are working on it right now.
Stacking is never as easy as it sounds :)
-Eric
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Eric Paris @ 2011-05-13 15:10 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Peter Zijlstra, Steven Rostedt, Tejun Heo,
Thomas Gleixner, linux-arm-kernel, Michal Marek, Michal Simek,
Will Drewry, linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110513121034.GG21022@elte.hu>
[dropping microblaze and roland]
lOn Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
> * James Morris <jmorris@namei.org> wrote:
> It is a simple and sensible security feature, agreed? It allows most code to
> run well and link to countless libraries - but no access to other files is
> allowed.
It's simple enough and sounds reasonable, but you can read all the
discussion about AppArmour why many people don't really think it's the
best. Still, I'll agree it's a lot better than nothing.
> But if i had a VFS event at the fs/namei.c::getname() level, i would have
> access to a central point where the VFS string becomes stable to the kernel and
> can be checked (and denied if necessary).
>
> A sidenote, and not surprisingly, the audit subsystem already has an event
> callback there:
>
> audit_getname(result);
>
> Unfortunately this audit callback cannot be used for my purposes, because the
> event is single-purpose for auditd and because it allows no feedback (no
> deny/accept discretion for the security policy).
>
> But if had this simple event there:
>
> err = event_vfs_getname(result);
Wow it sounds so easy. Now lets keep extending your train of thought
until we can actually provide the security provided by SELinux. What do
we end up with? We end up with an event hook right next to every LSM
hook. You know, the LSM hooks were placed where they are for a reason.
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. Why? It seems much easier that if you want the
language of the filter engine you would just make a new LSM that uses
the filter engine for it's policy language rather than the language
created by SELinux or SMACK or name your LSM implementation.
> - unprivileged: application-definable, allowing the embedding of security
> policy in *apps* as well, not just the system
>
> - flexible: can be added/removed runtime unprivileged, and cheaply so
>
> - transparent: does not impact executing code that meets the policy
>
> - nestable: it is inherited by child tasks and is fundamentally stackable,
> multiple policies will have the combined effect and they
> are transparent to each other. So if a child task within a
> sandbox adds *more* checks then those add to the already
> existing set of checks. We only narrow permissions, never
> extend them.
>
> - generic: allowing observation and (safe) control of security relevant
> parameters not just at the system call boundary but at other
> relevant places of kernel execution as well: which
> points/callbacks could also be used for other types of event
> extraction such as perf. It could even be shared with audit ...
I'm not arguing that any of these things are bad things. What you
describe 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
process shouldn't be allowed to control it's own access decisions in a
more flexible way than rwx bits. Then again, I certainly don't see a
reason that this syscall hardening patch should be held up while a whole
new concept in computer security is contemplated...
-Eric
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-13 15:02 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <1305294936.2466.65.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2011-05-13 at 14:49 +0200, Ingo Molnar wrote:
> >
> > So given that by your own admission it makes sense to share the facilities at
> > the low level, i also argue that it makes sense to share as high up as
> > possible.
>
> I'm not saying any such thing, I'm saying that it might make sense to
> observe active objects and auto-create these observation points. That
> doesn't make them similar or make them share anything.
Well, they would share the lowest level call site:
result = check_event_vfs_getname(result);
You call it 'auto-generated call site', i call it a shared (single line) call
site. The same thing as far as the lowest level goes.
Now (the way i understood it) you'd want to stop the sharing right after that.
I argue that it should go all the way up.
Note: i fully agree that there should be events where filters can have no
effect whatsoever. For example if this was written as:
check_event_vfs_getname(result);
Then it would have no effect. This is decided by the subsystem developers,
obviously. So whether an event is 'active' or 'passive' can be enforced at the
subsystem level as well.
As far as the event facilities go, 'no effect observation' is a special-case of
'active observation' - just like read-only files are a special case of
read-write files.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-13 14:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, Steven Rostedt, Martin Schwidefsky,
Thomas Gleixner, Roland McGrath, Michal Marek, Michal Simek,
Will Drewry, linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Tejun Heo, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <1305294935.2466.64.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> Cut the microblaze list since its bouncy.
>
> On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > > On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
> > > > I think the sanest semantics is to run all active callbacks as well.
> > > >
> > > > For example if this is used for three stacked security policies - as if 3 LSM
> > > > modules were stacked at once. We'd call all three, and we'd determine that at
> > > > least one failed - and we'd return a failure.
> > >
> > > But that only works for boolean functions where you can return the
> > > multi-bit-or of the result. What if you need to return the specific
> > > error code.
> >
> > Do you mean that one filter returns -EINVAL while the other -EACCES?
> >
> > Seems like a non-problem to me, we'd return the first nonzero value.
>
> Assuming the first is -EINVAL, what then is the value in computing the
> -EACCESS? Sounds like a massive waste of time to me.
No, because the common case is no rejection - this is a security mechanism. So
in the normal case we would execute all 3 anyway, just to determine that all
return 0.
Are you really worried about the abnormal case of one of them returning an
error and us calculating all 3 return values?
> > > Also, there's bound to be other cases where people will want to employ
> > > this, look at all the various notifier chain muck we've got, it already
> > > deals with much of this -- simply because users need it.
> >
> > Do you mean it would be easy to abuse it? What kind of abuse are you most
> > worried about?
>
> I'm not worried about abuse, I'm saying that going by the existing
> notifier pattern always visiting all entries on the callback list is
> undesired.
That is because many notifier chains are used in an 'event consuming' manner -
they are responding to things like hardware events and are called in an
interrupt-handler alike fashion most of the time.
> > > Then there's the whole indirection argument, if you don't need
> > > indirection, its often better to not use it, I myself much prefer code
> > > to look like:
> > >
> > > foo1(bar);
> > > foo2(bar);
> > > foo3(bar);
> > >
> > > Than:
> > >
> > > foo_notifier(bar);
> > >
> > > Simply because its much clearer who all are involved without me having
> > > to grep around to see who registers for foo_notifier and wth they do
> > > with it. It also makes it much harder to sneak in another user, whereas
> > > its nearly impossible to find new notifier users.
> > >
> > > Its also much faster, no extra memory accesses, no indirect function
> > > calls, no other muck.
> >
> > But i suspect this question has been settled, given the fact that even pure
> > observer events need and already process a chain of events? Am i missing
> > something about your argument?
>
> I'm saying that there's reasons to not use notifiers passive or active.
>
> Mostly the whole notifier/indirection muck comes up once you want
> modules to make use of the thing, because then you need dynamic
> management of the callback list.
But your argument assumes that we'd have a chain of functions to call, like
regular notifiers.
While the natural model here would be to have a list of registered event
structs for that point, with different filters but basically the same callback
mechanism (a call into the filter engine in essence).
Also note that the common case would be no event registered - and we'd
automatically optimize that case via the existing jump labels optimization.
> (Then again, I'm fairly glad we don't have explicit callbacks in kernel/cpu.c
> for all the cpu-hotplug callbacks :-)
>
> Anyway, I oppose for the existing events to gain an active role.
Why if 'being active' is optional and useful?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-13 13:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, Steven Rostedt, Martin Schwidefsky,
Thomas Gleixner, Roland McGrath, Michal Marek, Michal Simek,
Will Drewry, linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Tejun Heo, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110513131800.GA7883@elte.hu>
Cut the microblaze list since its bouncy.
On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> > On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
> > > I think the sanest semantics is to run all active callbacks as well.
> > >=20
> > > For example if this is used for three stacked security policies - as =
if 3 LSM=20
> > > modules were stacked at once. We'd call all three, and we'd determine=
that at=20
> > > least one failed - and we'd return a failure.=20
> >=20
> > But that only works for boolean functions where you can return the
> > multi-bit-or of the result. What if you need to return the specific
> > error code.
>=20
> Do you mean that one filter returns -EINVAL while the other -EACCES?
>=20
> Seems like a non-problem to me, we'd return the first nonzero value.
Assuming the first is -EINVAL, what then is the value in computing the
-EACCESS? Sounds like a massive waste of time to me.
> > Also, there's bound to be other cases where people will want to employ
> > this, look at all the various notifier chain muck we've got, it already
> > deals with much of this -- simply because users need it.
>=20
> Do you mean it would be easy to abuse it? What kind of abuse are you most=
=20
> worried about?
I'm not worried about abuse, I'm saying that going by the existing
notifier pattern always visiting all entries on the callback list is
undesired.
> > Then there's the whole indirection argument, if you don't need
> > indirection, its often better to not use it, I myself much prefer code
> > to look like:
> >=20
> > foo1(bar);
> > foo2(bar);
> > foo3(bar);
> >=20
> > Than:
> >=20
> > foo_notifier(bar);
> >=20
> > Simply because its much clearer who all are involved without me having
> > to grep around to see who registers for foo_notifier and wth they do
> > with it. It also makes it much harder to sneak in another user, whereas
> > its nearly impossible to find new notifier users.
> >=20
> > Its also much faster, no extra memory accesses, no indirect function
> > calls, no other muck.
>=20
> But i suspect this question has been settled, given the fact that even pu=
re=20
> observer events need and already process a chain of events? Am i missing=
=20
> something about your argument?
I'm saying that there's reasons to not use notifiers passive or active.
Mostly the whole notifier/indirection muck comes up once you want
modules to make use of the thing, because then you need dynamic
management of the callback list.
(Then again, I'm fairly glad we don't have explicit callbacks in
kernel/cpu.c for all the cpu-hotplug callbacks :-)
Anyway, I oppose for the existing events to gain an active role.
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-13 13:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <20110513124902.GC3924@elte.hu>
On Fri, 2011-05-13 at 14:49 +0200, Ingo Molnar wrote:
>=20
> So given that by your own admission it makes sense to share the facilitie=
s at=20
> the low level, i also argue that it makes sense to share as high up as=
=20
> possible.=20
I'm not saying any such thing, I'm saying that it might make sense to
observe active objects and auto-create these observation points. That
doesn't make them similar or make them share anything.
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-13 13:18 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <1305292132.2466.26.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
> > I think the sanest semantics is to run all active callbacks as well.
> >
> > For example if this is used for three stacked security policies - as if 3 LSM
> > modules were stacked at once. We'd call all three, and we'd determine that at
> > least one failed - and we'd return a failure.
>
> But that only works for boolean functions where you can return the
> multi-bit-or of the result. What if you need to return the specific
> error code.
Do you mean that one filter returns -EINVAL while the other -EACCES?
Seems like a non-problem to me, we'd return the first nonzero value.
> Also, there's bound to be other cases where people will want to employ
> this, look at all the various notifier chain muck we've got, it already
> deals with much of this -- simply because users need it.
Do you mean it would be easy to abuse it? What kind of abuse are you most
worried about?
> Then there's the whole indirection argument, if you don't need
> indirection, its often better to not use it, I myself much prefer code
> to look like:
>
> foo1(bar);
> foo2(bar);
> foo3(bar);
>
> Than:
>
> foo_notifier(bar);
>
> Simply because its much clearer who all are involved without me having
> to grep around to see who registers for foo_notifier and wth they do
> with it. It also makes it much harder to sneak in another user, whereas
> its nearly impossible to find new notifier users.
>
> Its also much faster, no extra memory accesses, no indirect function
> calls, no other muck.
But i suspect this question has been settled, given the fact that even pure
observer events need and already process a chain of events? Am i missing
something about your argument?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-13 13:08 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <20110513125452.GD3924@elte.hu>
On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
> I think the sanest semantics is to run all active callbacks as well.
>=20
> For example if this is used for three stacked security policies - as if 3=
LSM=20
> modules were stacked at once. We'd call all three, and we'd determine tha=
t at=20
> least one failed - and we'd return a failure.=20
But that only works for boolean functions where you can return the
multi-bit-or of the result. What if you need to return the specific
error code.
Also, there's bound to be other cases where people will want to employ
this, look at all the various notifier chain muck we've got, it already
deals with much of this -- simply because users need it.
Then there's the whole indirection argument, if you don't need
indirection, its often better to not use it, I myself much prefer code
to look like:
foo1(bar);
foo2(bar);
foo3(bar);
Than:
foo_notifier(bar);
Simply because its much clearer who all are involved without me having
to grep around to see who registers for foo_notifier and wth they do
with it. It also makes it much harder to sneak in another user, whereas
its nearly impossible to find new notifier users.
Its also much faster, no extra memory accesses, no indirect function
calls, no other muck.
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-13 12:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <1305290612.2466.17.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote:
> >
> > > event_vfs_getname(result);
> > > result = check_event_vfs_getname(result);
>
> Another fundamental difference is how to treat the callback chains for
> these two.
>
> Observers won't have a return value and are assumed to never fail,
> therefore we can always call every entry on the callback list.
>
> Active things otoh do have a return value, and thus we need to have
> semantics that define what to do with that during callback iteration,
> when to continue and when to break. Thus for active elements its
> impossible to guarantee all entries will indeed be called.
I think the sanest semantics is to run all active callbacks as well.
For example if this is used for three stacked security policies - as if 3 LSM
modules were stacked at once. We'd call all three, and we'd determine that at
least one failed - and we'd return a failure.
Even if the first one failed already we'd still want to trigger *all* the
failures, because security policies like to know when they have triggered a
failure (regardless of other active policies) and want to see that failure
event (if they are logging such events).
So to me this looks pretty similar to observer callbacks as well, it's the
natural extension to an observer callback chain.
Observer callbacks are simply constant functions (to the caller), those which
never return failure and which never modify any of the parameters.
It's as if you argued that there should be separate syscalls/facilities for
handling readonly files versus handling read/write files.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-13 12:49 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <1305290370.2466.14.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> > Why should we have two callbacks next to each other:
> >
> > event_vfs_getname(result);
> > result = check_event_vfs_getname(result);
> >
> > if one could do it all?
>
> Did you actually read the bit where I said that check_event_* (although
> I still think that name sucks) could imply a matching event_*?
No, did not notice that - and yes that solves this particular problem.
So given that by your own admission it makes sense to share the facilities at
the low level, i also argue that it makes sense to share as high up as
possible.
Are you perhaps arguing for a ->observe flag that would make 100% sure that the
default behavior for events is observe-only? That would make sense indeed.
Otherwise both cases really want to use all the same facilities for event
discovery, setup, control and potential extraction of events.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-13 12:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <1305290370.2466.14.camel@twins>
On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote:
>=20
> > event_vfs_getname(result);
> > result =3D check_event_vfs_getname(result);=20
Another fundamental difference is how to treat the callback chains for
these two.
Observers won't have a return value and are assumed to never fail,
therefore we can always call every entry on the callback list.
Active things otoh do have a return value, and thus we need to have
semantics that define what to do with that during callback iteration,
when to continue and when to break. Thus for active elements its
impossible to guarantee all entries will indeed be called.
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-13 12:39 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <20110513122646.GA3924@elte.hu>
On Fri, 2011-05-13 at 14:26 +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
>=20
> > On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
> > > err =3D event_vfs_getname(result);
> >=20
> > I really think we should not do this. Events like we have them should b=
e=20
> > inactive, totally passive entities, only observe but not affect executi=
on=20
> > (other than the bare minimal time delay introduced by observance).
>=20
> Well, this patchset already demonstrates that we can use a single event=
=20
> callback for a rather useful purpose.
Can and should are two distinct things.
> Either it makes sense to do, in which case we should share facilities as =
much=20
> as possible, or it makes no sense, in which case we should not merge it a=
t all.
And I'm arguing we should _not_. Observing is radically different from
Affecting, at the very least the two things should have different
permission schemes. We should not confuse these two matters.
> > If you want another entity that is more active, please invent a new nam=
e for=20
> > it and create a new subsystem for them, now you could have these active=
=20
> > entities also have an (automatic) passive event side, but that's some d=
etail.
>=20
> Why should we have two callbacks next to each other:
>=20
> event_vfs_getname(result);
> result =3D check_event_vfs_getname(result);
>=20
> if one could do it all?
Did you actually read the bit where I said that check_event_* (although
I still think that name sucks) could imply a matching event_*?
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-13 12:26 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <1305289146.2466.8.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
> > err = event_vfs_getname(result);
>
> I really think we should not do this. Events like we have them should be
> inactive, totally passive entities, only observe but not affect execution
> (other than the bare minimal time delay introduced by observance).
Well, this patchset already demonstrates that we can use a single event
callback for a rather useful purpose.
Either it makes sense to do, in which case we should share facilities as much
as possible, or it makes no sense, in which case we should not merge it at all.
> If you want another entity that is more active, please invent a new name for
> it and create a new subsystem for them, now you could have these active
> entities also have an (automatic) passive event side, but that's some detail.
Why should we have two callbacks next to each other:
event_vfs_getname(result);
result = check_event_vfs_getname(result);
if one could do it all?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-13 12:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <20110513121034.GG21022@elte.hu>
On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
> err =3D event_vfs_getname(result);
I really think we should not do this. Events like we have them should be
inactive, totally passive entities, only observe but not affect
execution (other than the bare minimal time delay introduced by
observance).
If you want another entity that is more active, please invent a new name
for it and create a new subsystem for them, now you could have these
active entities also have an (automatic) passive event side, but that's
some detail.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox