Quoting Casey Schaufler ([EMAIL PROTECTED]):
--- Serge E. Hallyn [EMAIL PROTECTED] wrote:
Quoting Stephen Smalley ([EMAIL PROTECTED]):
On Tue, 2007-11-27 at 10:11 -0600, Serge E. Hallyn wrote:
Quoting Crispin Cowan ([EMAIL PROTECTED]):
Just the name sys_hijack makes me
Quoting Crispin Cowan ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Casey Schaufler ([EMAIL PROTECTED]):
Could y'all bring me up to speed on what this is intended to
accomplish so that I can understand the Smack implications?
It's basically like ptracing a process,
On Tue, 2007-11-27 at 16:38 -0600, Serge E. Hallyn wrote:
Quoting Stephen Smalley ([EMAIL PROTECTED]):
On Tue, 2007-11-27 at 10:11 -0600, Serge E. Hallyn wrote:
Quoting Crispin Cowan ([EMAIL PROTECTED]):
Just the name sys_hijack makes me concerned.
This post describes a bunch of
Quoting Stephen Smalley ([EMAIL PROTECTED]):
On Tue, 2007-11-27 at 16:38 -0600, Serge E. Hallyn wrote:
Quoting Stephen Smalley ([EMAIL PROTECTED]):
On Tue, 2007-11-27 at 10:11 -0600, Serge E. Hallyn wrote:
Quoting Crispin Cowan ([EMAIL PROTECTED]):
Just the name sys_hijack makes me
Any complaints or questions left here? I've got more people reporting
problems with NFS/SELinux and this is the first (and hardest) step to
making NFS and any genic LSM play nicely. If there are not any
problems how should this be pushed to linus? Through James Morris's
git tree? Through Chris
Here's a question, why is there this round about way of retrieving the
path of the task? Wouldn't it be slightly more efficient to store it
explicitly as character array within the task_struct ?
On Nov 28, 2007 8:20 AM, Tetsuo Handa
[EMAIL PROTECTED] wrote:
Andrew Blaich wrote:
Tetsuo's
Hello.
Andrew Blaich wrote:
Here's a question, why is there this round about way of retrieving the
path of the task? Wouldn't it be slightly more efficient to store it
explicitly as character array within the task_struct ?
I don't know the reason. But I guess that
(1) Printing the pathname
From: Casey Schaufler [EMAIL PROTECTED]
Bump the value of CAP_LAST_CAP to reflect the current last cap value.
It appears that the patch that introduced CAP_LAST_CAP and the patch
that introduced CAP_MAC_ADMIN came in more or less at the same time.
Signed-off-by: Casey Schaufler [EMAIL PROTECTED]
Quoting Casey Schaufler ([EMAIL PROTECTED]):
From: Casey Schaufler [EMAIL PROTECTED]
Bump the value of CAP_LAST_CAP to reflect the current last cap value.
It appears that the patch that introduced CAP_LAST_CAP and the patch
that introduced CAP_MAC_ADMIN came in more or less at the same time.
Serge E. Hallyn wrote:
Quoting Crispin Cowan ([EMAIL PROTECTED]):
Is there to be an LSM hook, so that modules can decide on an arbitrary
decision of whether to allow a hijack? So that this do the right
SELinux thing can be generalized for all LSMs to do the right thing.
Currently:
Tetsuo Handa [EMAIL PROTECTED] writes:
Hello.
James Morris wrote:
From memory, one approach under discussion was to add netfilter hooks to
the transport layer, which could be invoked correctly by each type of
protocol when the target process is selected.
If this is done for netfilter,
11 matches
Mail list logo
