On Fri, 30 Nov 2007, Crispin Cowan wrote:
> > The only case of this so far has been Multiadm, although there seems to be
> > no reason for it to stay out of tree.
> >
> Dazuko. It has the same yucky code issues as Talpa, but AFAIK is pure
> GPL2 and thus is clean on the license issues.
>
> Tha
James Morris wrote:
> On Fri, 30 Nov 2007, Crispin Cowan wrote:
>> restored faces a lot of challenges, but I hope that some kind of
>> solution can be found, because the alternative is to effectively force
>> vendors like Sophos to do it the "dirty" way by fishing in memory for
>> the syscall table
Quoting KaiGai Kohei ([EMAIL PROTECTED]):
> Serge E. Hallyn wrote:
> > The capability bounding set is a set beyond which capabilities
> > cannot grow. Currently cap_bset is per-system. It can be
> > manipulated through sysctl, but only init can add capabilities.
> > Root can remove capabilities.
Hello.
Thank you for detailed explanation.
Samir Bellabes wrote:
> By "filtering", you should mean "packets filtring", shouldn't you ?
> because this hook is able to deny the accept() syscall for a process, so
> it's a kind of "filtring" too.
Yes, you are right.
> No, it's performed from the use
Serge E. Hallyn wrote:
> The capability bounding set is a set beyond which capabilities
> cannot grow. Currently cap_bset is per-system. It can be
> manipulated through sysctl, but only init can add capabilities.
> Root can remove capabilities. By default it includes all caps
> except CAP_SETPCA
On Fri, 30 Nov 2007, Crispin Cowan wrote:
> restored faces a lot of challenges, but I hope that some kind of
> solution can be found, because the alternative is to effectively force
> vendors like Sophos to do it the "dirty" way by fishing in memory for
> the syscall table.
I don't think this is
Tvrtko A. Ursulin wrote:
> During one recent LKML discussion
> (http://marc.info/?l=linux-kernel&m=119267398722085&w=2) about
> LSM going
> static you called for LSM users to speak up.
Great big clue: If "LSM" is in the subject line, then cc: the LSM list
linux-security-module@vger.kernel.org
For
Quoting Paul Menage ([EMAIL PROTECTED]):
> On Nov 29, 2007 6:08 PM, Mark Nelson <[EMAIL PROTECTED]> wrote:
> > Hi Paul and Eric,
> >
> > Do you guys have any objections to dropping the hijack_pid() and
> > hijack_cgroup() parts of sys_hijack, leaving just hijack_ns() (see
> > below for discussion)?
Hello.
Thank you for feedback.
I have some questions.
(1) Your module uses "struct security_operations" and
is registered with register_security().
TOMOYO also uses "struct security_operations" and
must be registered with register_security().
Can your module and TOMOYO coexist?
Hello.
Samir Bellabes wrote:
> at security_socket_accept(), the user only accept the fact that the
> application is able to go to sock->ops->accept(). That's the purpose of
> this hook.
Yes. This hook can't perform filtering.
> After, when packet are coming, we can catch them with
> libnetfilter_
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> Mark Nelson <[EMAIL PROTECTED]> writes:
>
> > Hi Paul and Eric,
> >
> > Do you guys have any objections to dropping the hijack_pid() and
> > hijack_cgroup() parts of sys_hijack, leaving just hijack_ns() (see
> > below for discussion)?
>
> I need to
Tetsuo Handa <[EMAIL PROTECTED]> writes:
> Hello.
>
> Thank you for feedback.
>
> I have some questions.
>
> (1) Your module uses "struct security_operations" and
> is registered with register_security().
>
> TOMOYO also uses "struct security_operations" and
> must be registered with r
Tetsuo Handa <[EMAIL PROTECTED]> writes:
> Hello.
>
> Samir Bellabes wrote:
>> at security_socket_accept(), the user only accept the fact that the
>> application is able to go to sock->ops->accept(). That's the purpose of
>> this hook.
> Yes. This hook can't perform filtering.
By "filtering", you
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>> Mark Nelson <[EMAIL PROTECTED]> writes:
>>
>> > Hi Paul and Eric,
>> >
>> > Do you guys have any objections to dropping the hijack_pid() and
>> > hijack_cgroup() parts of sys_hijack, leaving just hij
Tetsuo Handa <[EMAIL PROTECTED]> writes:
> Hello.
> Thank you for detailed explanation.
> Samir Bellabes wrote:
>
>> No, it's performed from the userspace. the goal is to don't touch the
>> network stack at all.
> OK. One thing I'm worrying.
> Use of userspace process assumes that it shall not be
15 matches
Mail list logo
