On Thu, 12 Dec 2013, vegard.nos...@oracle.com wrote:
> diff --git a/security/exploit.c b/security/exploit.c
> new file mode 100644
> index 000..a732613
> --- /dev/null
> +++ b/security/exploit.c
> @@ -0,0 +1,28 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +void _ex
Hi Vegard,
On 12/12/2013 11:52 AM, vegard.nos...@oracle.com wrote:
> +#ifdef CONFIG_EXPLOIT_DETECTION
> +extern void _exploit(const char *id);
So right now the on/off switch is a kernel config option. I suggest we should
add another
dynamic switch (maybe in the form of jump labels) to add an ad
On 13/12/13 06:06, Theodore Ts'o wrote:
> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
>> From: Vegard Nossum
>>
>> The idea is simple -- since different kernel versions are vulnerable to
>> different root exploits, hackers most likely try multiple exploits before
>>
On 14/12/13 00:06, Ingo Molnar wrote:
>
> * Ryan Mallon wrote:
>
>> On 13/12/13 08:13, Kees Cook wrote:
>>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
> From: Vegard Nossum
>
> The idea is s
On 13/12/13 20:20, Vegard Nossum wrote:
> On 12/13/2013 12:50 AM, Ryan Mallon wrote:
>> On 13/12/13 08:13, Kees Cook wrote:
>>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
> The idea is simple -- since d
On Fri, Dec 13, 2013 at 10:14 AM, Linus Torvalds
wrote:
> On Fri, Dec 13, 2013 at 9:58 AM, Kees Cook wrote:
>>
>> These locations tend to be very hard to reach accidentally
>
> Not necessarily.
>
> Don't get me wrong - I think that it's a good idea to at least have
> the option to complain about
On Fri, Dec 13, 2013 at 9:58 AM, Kees Cook wrote:
>
> These locations tend to be very hard to reach accidentally
Not necessarily.
Don't get me wrong - I think that it's a good idea to at least have
the option to complain about certain errors, and leave markers in the
logs about things that look
On Thu, Dec 12, 2013 at 9:27 PM, Theodore Ts'o wrote:
> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>> > Suppose we put put this into the mainstream kernel. Wouldn't writers
>> > of root kit adapt by checking for the kernel version to avoid checking
>> > for exploits that are known
On Fri, Dec 13, 2013 at 5:23 AM, Ingo Molnar wrote:
>
> * Dan Carpenter wrote:
>
>> On Fri, Dec 13, 2013 at 11:31:48AM +0100, Alexander Holler wrote:
>> > I've never seen a comment inside the kernel sources which does point
>> > to a CVE, so I assume there already does exists some agreement about
On Thu, Dec 12, 2013 at 5:42 PM, Greg Kroah-Hartman
wrote:
> On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
>> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>>
>> > - who will keep adding these triggers going forward?
>>
>> also..
>>
>> - Who will test the existing trigg
On Fri, Dec 13, 2013 at 02:06:48PM +0100, Ingo Molnar wrote:
...
> In future the exploit() code could trigger actual active defensive
> measures, such as immediately freezing all tasks of that UID and
> blocking further fork()s/exec()s of that UID.
>
> Depending on how critical the security of t
On Fri, 13 Dec 2013, One Thousand Gnomes wrote:
> Note however if you trip one of those in any code with the console lock
> held and your log goes to the consoles due to printk level or similar
> you'll probably hang the box.
Also if someone is holding current->alloc_lock.
--
Jiri Kosina
SUSE L
* Vegard Nossum wrote:
> On 12/12/2013 10:13 PM, Kees Cook wrote:
>
> > I like it. I like how lightweight it is, and I like that it can be
> > trivially compiled out. My concerns would be:
> >
> > - how do we avoid bikeshedding about which exploits are "serious
> > enough" to trigger a report
* Dan Carpenter wrote:
> On Fri, Dec 13, 2013 at 11:31:48AM +0100, Alexander Holler wrote:
> > I've never seen a comment inside the kernel sources which does point
> > to a CVE, so I assume there already does exists some agreement about
> > not doing so.
>
> We do occasionally put CVE numbers i
* Theodore Ts'o wrote:
> On Fri, Dec 13, 2013 at 04:09:06PM +1100, James Morris wrote:
> >
> > I think we'd need to have someone commit to maintaining this long
> > term before seriously considering it as part of mainline. Over
> > time it will become increasingly useless if new triggers are
* Ryan Mallon wrote:
> On 13/12/13 08:13, Kees Cook wrote:
> > On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
> >> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
> >>> From: Vegard Nossum
> >>>
> >>> The idea is simple -- since different kernel versions are v
* vegard.nos...@oracle.com wrote:
> From: Vegard Nossum
>
> The idea is simple -- since different kernel versions are vulnerable
> to different root exploits, hackers most likely try multiple
> exploits before they actually succeed.
>
> Fixing an exploitable kernel bug usually means adding
On Fri, Dec 13, 2013 at 02:48:41PM +0300, Dan Carpenter wrote:
> On Fri, Dec 13, 2013 at 11:31:48AM +0100, Alexander Holler wrote:
> > I've never seen a comment inside the kernel sources which does point
> > to a CVE, so I assume there already does exists some agreement about
> > not doing so.
>
>
On Fri, Dec 13, 2013 at 11:31:48AM +0100, Alexander Holler wrote:
> I've never seen a comment inside the kernel sources which does point
> to a CVE, so I assume there already does exists some agreement about
> not doing so.
We do occasionally put CVE numbers in the commit message, but normally
the
> Totally true, but there's a million way to DoS a local machine. At
> least this way shows who's doing it. It's the DoSes that don't include
> attribution that I worry about. :)
So long as they compile out to nothingness for all the systems where this
stuff is useless (ie most of them because the
Am 13.12.2013 02:42, schrieb Greg Kroah-Hartman:
On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> - who will keep adding these triggers going forward?
also..
- Who will test the existing triggers are doing the right thi
On 12/13/2013 06:09 AM, James Morris wrote:
On Thu, 12 Dec 2013, Greg Kroah-Hartman wrote:
On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> - who will keep adding these triggers going forward?
I think we'd need to ha
On Fri, 13 Dec 2013, Theodore Ts'o wrote:
> I am at least partially sympathetic to the concerns which Greg has
> raised, though. At the very least the exploit() tags should also have
> a date stamp, so it we can automatically scan for exploit tags whose
> time has come and gone.
At least this is
On 12/13/2013 12:50 AM, Ryan Mallon wrote:
On 13/12/13 08:13, Kees Cook wrote:
On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
The idea is simple -- since different kernel versions are vulnerable to
different roo
On 12/12/2013 10:13 PM, Kees Cook wrote:
On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
The idea is simple -- since different kernel versions are vulnerable to
different root exploits, hackers most likely try mul
On 12/12/2013 08:06 PM, Theodore Ts'o wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
The idea is simple -- since different kernel versions are vulnerable to
different root exploits, hackers most likely try multiple exploits before
they actually succeed.
Suppos
On Fri, Dec 13, 2013 at 04:09:06PM +1100, James Morris wrote:
>
> I think we'd need to have someone commit to maintaining this long term
> before seriously considering it as part of mainline. Over time it will
> become increasingly useless if new triggers aren't added.
>
> What happens when co
On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> > Suppose we put put this into the mainstream kernel. Wouldn't writers
> > of root kit adapt by checking for the kernel version to avoid checking
> > for exploits that are known not work? So the question is whether the
> > additional co
On Thu, 12 Dec 2013, Greg Kroah-Hartman wrote:
> On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
> > On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> >
> > > - who will keep adding these triggers going forward?
> >
I think we'd need to have someone commit to maintaining
On Thu, Dec 12, 2013 at 05:42:20PM -0800, Greg Kroah-Hartman wrote:
> I really don't like this, it means that our normal error handling for
> userspace data will suddenly all have CVE entries on them over time.
> How is that helpful to anyone?
>
> Think ahead in 10-20 years, what is the code
On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>
> > - who will keep adding these triggers going forward?
>
> also..
>
> - Who will test the existing triggers are doing the right thing when related
> code changes.
And:
On Thu, Dec 12, 2013 at 4:25 PM, Dave Jones wrote:
> On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
>
> > - who will keep adding these triggers going forward?
>
> also..
>
> - Who will test the existing triggers are doing the right thing when related
> code changes.
>
> We could add
On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> - who will keep adding these triggers going forward?
also..
- Who will test the existing triggers are doing the right thing when related
code changes.
We could add something to tests/ maybe for each exploit() addition, to make
sure
On Thu, Dec 12, 2013 at 3:50 PM, Ryan Mallon wrote:
> On 13/12/13 08:13, Kees Cook wrote:
>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
>>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
From: Vegard Nossum
The idea is simple -- since differe
On 13/12/13 08:13, Kees Cook wrote:
> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
>>> From: Vegard Nossum
>>>
>>> The idea is simple -- since different kernel versions are vulnerable to
>>> different root expl
On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
>> From: Vegard Nossum
>>
>> The idea is simple -- since different kernel versions are vulnerable to
>> different root exploits, hackers most likely try multiple expl
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
> From: Vegard Nossum
>
> The idea is simple -- since different kernel versions are vulnerable to
> different root exploits, hackers most likely try multiple exploits before
> they actually succeed.
Suppose we put put this
From: Vegard Nossum
The idea is simple -- since different kernel versions are vulnerable to
different root exploits, hackers most likely try multiple exploits before
they actually succeed.
Fixing an exploitable kernel bug usually means adding a check to see if
what a userspace program tried to d
38 matches
Mail list logo
