FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 05-12-2010, 10:22 PM
Kees Cook
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

As Linux grows in popularity, it will become a growing target for
malware. One particularly troubling weakness of the Linux process
interfaces is that a single user is able to examine the memory and
running state of any of their processes. For example, if one application
(e.g. Empathy) was compromised, it would be possible for an attacker to
attach to other processes (e.g. Firefox) to extract additional credentials
and continue to expand the scope of their attack.

For a solution, some applications use prctl() to specifically disallow
such PTRACE attachment (e.g. ssh-agent). A more general solution is to
only allow PTRACE directly from a parent to a child process (i.e. direct
gdb and strace still work), or as the root user (i.e. gdb BIN PID,
and strace -p PID still work as root).

This patch is based on the patch in grsecurity. I have added a sysctl to
toggle the behavior back to the old scope via /proc/sys/kernel/ptrace_scope.

Signed-off-by: Kees Cook <kees.cook@canonical.com>
---
kernel/ptrace.c | 24 ++++++++++++++++++++++++
kernel/sysctl.c | 10 ++++++++++
2 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 42ad8ae..ad80b43 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -24,6 +24,8 @@
#include <linux/uaccess.h>
#include <linux/regset.h>

+/* sysctl for defining allowed scope of PTRACE */
+int ptrace_scope = 1;

/*
* ptrace a task: make the debugger its new parent and
@@ -129,6 +131,10 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
* ptrace_attach denies several cases that /proc allows
* because setting up the necessary parent/child relationship
* or halting the specified task is impossible.
+ *
+ * PTRACE scope can be define as:
+ * 0 - classic: CAP_SYS_PTRACE and same uid can ptrace non-setuid
+ * 1 - restricted: as above, but only children of ptracing process
*/
int dumpable = 0;
/* Don't let security modules deny introspection */
@@ -152,6 +158,24 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
dumpable = get_dumpable(task->mm);
if (!dumpable && !capable(CAP_SYS_PTRACE))
return -EPERM;
+ if (ptrace_scope && !capable(CAP_SYS_PTRACE)) {
+ /* require ptrace target be a child of ptracer */
+ struct task_struct *tmp = task;
+ struct task_struct *curtemp = current;
+ int rc = 0;
+
+ read_lock(&tasklist_lock);
+ while (tmp->pid > 0) {
+ if (tmp == curtemp)
+ break;
+ tmp = tmp->parent;
+ }
+ if (tmp->pid == 0)
+ rc = -EPERM;
+ read_unlock(&tasklist_lock);
+ if (rc)
+ return rc;
+ }

return security_ptrace_access_check(task, mode);
}
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 4f3ffd0..992eba9 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -84,6 +84,7 @@ extern int sysctl_panic_on_oom;
extern int sysctl_oom_kill_allocating_task;
extern int sysctl_oom_dump_tasks;
extern int max_threads;
+extern int ptrace_scope;
extern int core_uses_pid;
extern int suid_dumpable;
extern int weak_sticky_symlinks;
@@ -382,6 +383,15 @@ static struct ctl_table kern_table[] = {
.proc_handler = proc_dointvec,
},
{
+ .procname = "ptrace_scope",
+ .data = &ptrace_scope,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &one,
+ },
+ {
.procname = "core_uses_pid",
.data = &core_uses_pid,
.maxlen = sizeof(int),
--
1.7.0.4


--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-13-2010, 08:13 AM
Scott James Remnant
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

On Wed, 2010-05-12 at 15:22 -0700, Kees Cook wrote:

> As Linux grows in popularity, it will become a growing target for
> malware. One particularly troubling weakness of the Linux process
> interfaces is that a single user is able to examine the memory and
> running state of any of their processes. For example, if one application
> (e.g. Empathy) was compromised, it would be possible for an attacker to
> attach to other processes (e.g. Firefox) to extract additional credentials
> and continue to expand the scope of their attack.
>
This is completely possible anyway, even with your patch. I would do
the following:

- send SIGSTOP to the compositor to disable screen updates

- send command to firefox to save browser state and exit
(or SIGKILL)

- fork/exec firefox again (will reappear on the screen as it was
before)

- firefox is now your child, ptrace

- send SIGCONT to the compositor to resume screen updates

Firefox is now being ptraced, but the user never knows what happens.


So your patch adds inconvenience for no additional security, thus I
object to this.

Scott
--
Scott James Remnant
scott@ubuntu.com
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-13-2010, 08:33 AM
Kees Cook
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

Hi Scott,

On Thu, May 13, 2010 at 10:13:27AM +0200, Scott James Remnant wrote:
> On Wed, 2010-05-12 at 15:22 -0700, Kees Cook wrote:
>
> > As Linux grows in popularity, it will become a growing target for
> > malware. One particularly troubling weakness of the Linux process
> > interfaces is that a single user is able to examine the memory and
> > running state of any of their processes. For example, if one application
> > (e.g. Empathy) was compromised, it would be possible for an attacker to
> > attach to other processes (e.g. Firefox) to extract additional credentials
> > and continue to expand the scope of their attack.
> >
> This is completely possible anyway, even with your patch. I would do
> the following:
>
> - send SIGSTOP to the compositor to disable screen updates
>
> - send command to firefox to save browser state and exit
> (or SIGKILL)
>
> - fork/exec firefox again (will reappear on the screen as it was
> before)
>
> - firefox is now your child, ptrace
>
> - send SIGCONT to the compositor to resume screen updates
>
> Firefox is now being ptraced, but the user never knows what happens.

This patch is specifically for blocking access to processes that hold
credentials in memory but don't set prctl[1]. This change pro-actively
helps protect such scenarios.

Firefox was just an example. I could have just as well used other stuff
that doesn't save state as well. I totally admit that trying to defend
the user from the user is a losing game, but I do feel that layered
defense is still worth it when it is both configurable and doesn't cause
problems for the general case.

> So your patch adds inconvenience for no additional security, thus I
> object to this.

Having developers/admins use sudo or add a file to /etc/sysctl.d to
restore the original PTRACE behavior isn't much of an inconvenience.

-Kees

[1] https://launchpad.net/bugs/572045

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-13-2010, 08:39 AM
Scott James Remnant
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

On Thu, 2010-05-13 at 01:33 -0700, Kees Cook wrote:

> This patch is specifically for blocking access to processes that hold
> credentials in memory but don't set prctl[1]. This change pro-actively
> helps protect such scenarios.
>
Why don't you just fix the apps concerned to use prctl() or to lock
their memory?

> > So your patch adds inconvenience for no additional security, thus I
> > object to this.
>
> Having developers/admins use sudo or add a file to /etc/sysctl.d to
> restore the original PTRACE behavior isn't much of an inconvenience.
>
I disagree in the strongest terms.

If security gets in the way of people using their computers, they will
simply disable it.

Fedora's SELinux policy

Windows' UAC

Being able to debug processes running as your user is an important tool
for developers. This will annoy the hell out of them, and they will
disable your patch.

That means we'll get less testing of your patch, and potential problems
will be hidden from us until release.

I really dislike these meme that it's acceptable for developers to have
to add toggles or files to restore a system to a state they can work
with; not because we should be developer focussed, but because our
developers are still our primary testers.


I would far prefer to individual apps jailed from each other entirely,
empathy shouldn't be *able* to exec firefox, etc.

Scott
--
Scott James Remnant
scott@ubuntu.com
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-13-2010, 08:59 AM
Kees Cook
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

On Thu, May 13, 2010 at 10:39:48AM +0200, Scott James Remnant wrote:
> On Thu, 2010-05-13 at 01:33 -0700, Kees Cook wrote:
> > This patch is specifically for blocking access to processes that hold
> > credentials in memory but don't set prctl[1]. This change pro-actively
> > helps protect such scenarios.
> >
> Why don't you just fix the apps concerned to use prctl() or to lock
> their memory?

Well, I intend to, which is why the bug exists, but there will always be
new software. That's why this is considered "pro-active" defense.

> > Having developers/admins use sudo or add a file to /etc/sysctl.d to
> > restore the original PTRACE behavior isn't much of an inconvenience.
> >
> I disagree in the strongest terms.

Understood.

> If security gets in the way of people using their computers, they will
> simply disable it.
>
> Fedora's SELinux policy
> Windows' UAC

I couldn't agree more, and am very aware of these situations. I just
disagree with you about the level of inconvenience and the size of the
affected audience.

> Being able to debug processes running as your user is an important tool
> for developers. This will annoy the hell out of them, and they will
> disable your patch.

They will disable the sysctl setting or gain CAP_SYS_PTRACE temporarily.

> That means we'll get less testing of your patch, and potential problems
> will be hidden from us until release.

I believe the set of people testing maverick that does not disable this
feature system-wide will be sufficiently large to gain meaningful testing.

> I really dislike these meme that it's acceptable for developers to have
> to add toggles or files to restore a system to a state they can work
> with; not because we should be developer focussed, but because our
> developers are still our primary testers.

It sounds like you object to the default setting, not the feature itself.

> I would far prefer to individual apps jailed from each other entirely,
> empathy shouldn't be *able* to exec firefox, etc.

I totally agree. This isn't possible now, so I am proposing improvements
to the existing methodologies.

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-26-2010, 07:31 PM
Tim Gardner
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

On 05/13/2010 02:59 AM, Kees Cook wrote:
> On Thu, May 13, 2010 at 10:39:48AM +0200, Scott James Remnant wrote:
>> On Thu, 2010-05-13 at 01:33 -0700, Kees Cook wrote:
>>> This patch is specifically for blocking access to processes that hold
>>> credentials in memory but don't set prctl[1]. This change pro-actively
>>> helps protect such scenarios.
>>>
>> Why don't you just fix the apps concerned to use prctl() or to lock
>> their memory?
>
> Well, I intend to, which is why the bug exists, but there will always be
> new software. That's why this is considered "pro-active" defense.
>
>>> Having developers/admins use sudo or add a file to /etc/sysctl.d to
>>> restore the original PTRACE behavior isn't much of an inconvenience.
>>>
>> I disagree in the strongest terms.
>
> Understood.
>
>> If security gets in the way of people using their computers, they will
>> simply disable it.
>>
>> Fedora's SELinux policy
>> Windows' UAC
>
> I couldn't agree more, and am very aware of these situations. I just
> disagree with you about the level of inconvenience and the size of the
> affected audience.
>
>> Being able to debug processes running as your user is an important tool
>> for developers. This will annoy the hell out of them, and they will
>> disable your patch.
>
> They will disable the sysctl setting or gain CAP_SYS_PTRACE temporarily.
>
>> That means we'll get less testing of your patch, and potential problems
>> will be hidden from us until release.
>
> I believe the set of people testing maverick that does not disable this
> feature system-wide will be sufficiently large to gain meaningful testing.
>
>> I really dislike these meme that it's acceptable for developers to have
>> to add toggles or files to restore a system to a state they can work
>> with; not because we should be developer focussed, but because our
>> developers are still our primary testers.
>
> It sounds like you object to the default setting, not the feature itself.
>
>> I would far prefer to individual apps jailed from each other entirely,
>> empathy shouldn't be *able* to exec firefox, etc.
>
> I totally agree. This isn't possible now, so I am proposing improvements
> to the existing methodologies.
>
> -Kees
>

Is it safe to assume that developers that might encounter this minor
restriction would also have ubuntu-dev-tools installed? We could add
something to that package that swizzles /proc/sys/kernel/ptrace_scope,
thereby avoiding inconvenience to developers while still providing a
good test for the normal install.

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-26-2010, 08:01 PM
Tim Gardner
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

On 05/12/2010 04:22 PM, Kees Cook wrote:

As Linux grows in popularity, it will become a growing target for
malware. One particularly troubling weakness of the Linux process
interfaces is that a single user is able to examine the memory and
running state of any of their processes. For example, if one application
(e.g. Empathy) was compromised, it would be possible for an attacker to
attach to other processes (e.g. Firefox) to extract additional credentials
and continue to expand the scope of their attack.

For a solution, some applications use prctl() to specifically disallow
such PTRACE attachment (e.g. ssh-agent). A more general solution is to
only allow PTRACE directly from a parent to a child process (i.e. direct
gdb and strace still work), or as the root user (i.e. gdb BIN PID,
and strace -p PID still work as root).

This patch is based on the patch in grsecurity. I have added a sysctl to
toggle the behavior back to the old scope via /proc/sys/kernel/ptrace_scope.

Signed-off-by: Kees Cook<kees.cook@canonical.com>
---
kernel/ptrace.c | 24 ++++++++++++++++++++++++
kernel/sysctl.c | 10 ++++++++++
2 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 42ad8ae..ad80b43 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -24,6 +24,8 @@
#include<linux/uaccess.h>
#include<linux/regset.h>

+/* sysctl for defining allowed scope of PTRACE */
+int ptrace_scope = 1;

/*
* ptrace a task: make the debugger its new parent and
@@ -129,6 +131,10 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
* ptrace_attach denies several cases that /proc allows
* because setting up the necessary parent/child relationship
* or halting the specified task is impossible.
+ *
+ * PTRACE scope can be define as:
+ * 0 - classic: CAP_SYS_PTRACE and same uid can ptrace non-setuid
+ * 1 - restricted: as above, but only children of ptracing process
*/
int dumpable = 0;
/* Don't let security modules deny introspection */
@@ -152,6 +158,24 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
dumpable = get_dumpable(task->mm);
if (!dumpable&& !capable(CAP_SYS_PTRACE))
return -EPERM;
+ if (ptrace_scope&& !capable(CAP_SYS_PTRACE)) {
+ /* require ptrace target be a child of ptracer */
+ struct task_struct *tmp = task;
+ struct task_struct *curtemp = current;
+ int rc = 0;
+
+ read_lock(&tasklist_lock);
+ while (tmp->pid> 0) {
+ if (tmp == curtemp)
+ break;
+ tmp = tmp->parent;
+ }
+ if (tmp->pid == 0)
+ rc = -EPERM;
+ read_unlock(&tasklist_lock);
+ if (rc)
+ return rc;
+ }

return security_ptrace_access_check(task, mode);
}
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 4f3ffd0..992eba9 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -84,6 +84,7 @@ extern int sysctl_panic_on_oom;
extern int sysctl_oom_kill_allocating_task;
extern int sysctl_oom_dump_tasks;
extern int max_threads;
+extern int ptrace_scope;
extern int core_uses_pid;
extern int suid_dumpable;
extern int weak_sticky_symlinks;
@@ -382,6 +383,15 @@ static struct ctl_table kern_table[] = {
.proc_handler = proc_dointvec,
},
{
+ .procname = "ptrace_scope",
+ .data =&ptrace_scope,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 =&zero,
+ .extra2 =&one,
+ },
+ {
.procname = "core_uses_pid",
.data =&core_uses_pid,
.maxlen = sizeof(int),


Arguments for the inconvenience or effectiveness of this patch aside, it
appears to do what you'd expect. See attached.


Acked-by: Tim Gardner <tim.gardner@canonical.com>

--
Tim Gardner tim.gardner@canonical.com
rtg@xps1330:/proc/sys/kernel$ echo 0 | sudo tee ptrace_scope
0
rtg@xps1330:/proc/sys/kernel$ ps|grep bash|while read pid j;do strace -p$pid;done
Process 2438 attached - interrupt to quit
wait4(-1, ^C <unfinished ...>
Process 2438 detached
Process 2524 attached - interrupt to quit
wait4(-1, ^C <unfinished ...>
Process 2524 detached

rtg@xps1330:/proc/sys/kernel$ echo 1 | sudo tee ptrace_scope
1
rtg@xps1330:/proc/sys/kernel$ ps|grep bash|while read pid j;do strace -p$pid;done
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-26-2010, 08:15 PM
Chase Douglas
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

On Wed, 2010-05-12 at 15:22 -0700, Kees Cook wrote:
> As Linux grows in popularity, it will become a growing target for
> malware. One particularly troubling weakness of the Linux process
> interfaces is that a single user is able to examine the memory and
> running state of any of their processes. For example, if one application
> (e.g. Empathy) was compromised, it would be possible for an attacker to
> attach to other processes (e.g. Firefox) to extract additional credentials
> and continue to expand the scope of their attack.
>
> For a solution, some applications use prctl() to specifically disallow
> such PTRACE attachment (e.g. ssh-agent). A more general solution is to
> only allow PTRACE directly from a parent to a child process (i.e. direct
> gdb and strace still work), or as the root user (i.e. gdb BIN PID,
> and strace -p PID still work as root).
>
> This patch is based on the patch in grsecurity. I have added a sysctl to
> toggle the behavior back to the old scope via /proc/sys/kernel/ptrace_scope.
>
> Signed-off-by: Kees Cook <kees.cook@canonical.com>
> ---
> kernel/ptrace.c | 24 ++++++++++++++++++++++++
> kernel/sysctl.c | 10 ++++++++++
> 2 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index 42ad8ae..ad80b43 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -24,6 +24,8 @@
> #include <linux/uaccess.h>
> #include <linux/regset.h>
>
> +/* sysctl for defining allowed scope of PTRACE */
> +int ptrace_scope = 1;
>
> /*
> * ptrace a task: make the debugger its new parent and
> @@ -129,6 +131,10 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> * ptrace_attach denies several cases that /proc allows
> * because setting up the necessary parent/child relationship
> * or halting the specified task is impossible.
> + *
> + * PTRACE scope can be define as:
> + * 0 - classic: CAP_SYS_PTRACE and same uid can ptrace non-setuid
> + * 1 - restricted: as above, but only children of ptracing process
> */
> int dumpable = 0;
> /* Don't let security modules deny introspection */
> @@ -152,6 +158,24 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> dumpable = get_dumpable(task->mm);
> if (!dumpable && !capable(CAP_SYS_PTRACE))
> return -EPERM;
> + if (ptrace_scope && !capable(CAP_SYS_PTRACE)) {
> + /* require ptrace target be a child of ptracer */
> + struct task_struct *tmp = task;
> + struct task_struct *curtemp = current;

Why create a new variable just to store current? I think it would be
more readable to just use current where you use curtemp. I don't think
current should change from under you when you're here.

> + int rc = 0;
> +
> + read_lock(&tasklist_lock);
> + while (tmp->pid > 0) {
> + if (tmp == curtemp)
> + break;
> + tmp = tmp->parent;
> + }
> + if (tmp->pid == 0)
> + rc = -EPERM;
> + read_unlock(&tasklist_lock);
> + if (rc)
> + return rc;
> + }
>
> return security_ptrace_access_check(task, mode);
> }


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-26-2010, 08:49 PM
Kees Cook
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

Hi Tim,

On Wed, May 26, 2010 at 01:31:07PM -0600, Tim Gardner wrote:
> Is it safe to assume that developers that might encounter this minor
> restriction would also have ubuntu-dev-tools installed? We could add
> something to that package that swizzles
> /proc/sys/kernel/ptrace_scope, thereby avoiding inconvenience to
> developers while still providing a good test for the normal install.

That's certainly a good idea. I can put the question to ubuntu-devel. The
two classes of people hit by this are "developers" and "sysadmins", both
really nebulous classes. If ubuntu-dev-tools adds a setting to
/etc/sysctl.d/, that could work. For sysadmins, I still think it would be
best to retrain them to either use "sudo" or temporarily turn on the
ptrace_scope setting, as the rest of their system probably shouldn't have
ptrace enabled normally. Regardless, I expect a lively discussion.

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-26-2010, 08:50 PM
Kees Cook
 
Default UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

Hi Chase,

On Wed, May 26, 2010 at 04:15:25PM -0400, Chase Douglas wrote:
> > + if (ptrace_scope && !capable(CAP_SYS_PTRACE)) {
> > + /* require ptrace target be a child of ptracer */
> > + struct task_struct *tmp = task;
> > + struct task_struct *curtemp = current;
>
> Why create a new variable just to store current? I think it would be
> more readable to just use current where you use curtemp. I don't think
> current should change from under you when you're here.
>
> > + int rc = 0;
> > +
> > + read_lock(&tasklist_lock);
> > + while (tmp->pid > 0) {
> > + if (tmp == curtemp)
> > + break;
> > + tmp = tmp->parent;
> > + }
> > + if (tmp->pid == 0)
> > + rc = -EPERM;
> > + read_unlock(&tasklist_lock);

That's a fair point -- I guess we're under lock the entire time. I'd be
fine to change it if other people agree it's safe looking.

-Kees

--
Kees Cook
Ubuntu Security Team

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 12:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org