On Monday 31 July 2006 8:43 am, Venkat Yekkirala wrote:
> > The NetLabel patch allows administrators to assign specific a CIPSO
> > DOI/configuration to each LSM "domain". Blindly using the
> > CIPSO tag that the
> > remote host sends could violate the administrator's NetLabel
> > configuration.
>
> The NetLabel patch allows administrators to assign specific a CIPSO
> DOI/configuration to each LSM "domain". Blindly using the
> CIPSO tag that the
> remote host sends could violate the administrator's NetLabel
> configuration.
>
> The current patch reads the CIPSO tag off the child sock
On Saturday 29 July 2006 12:34 pm, Venkat Yekkirala wrote:
> > > This is only true wart I see in the patch set from my
> > > perspective.
> > >
> > > You have security_post_accept_hook(), which gets the parent and
> > > the child socket which is all the information you need, and it
> > > seems to b
> > This is only true wart I see in the patch set from my
> > perspective.
> >
> > You have security_post_accept_hook(), which gets the parent and
> > the child socket which is all the information you need, and it
> > seems to be invoked at the correct location.
> >
> > So can you please hook int
David Miller wrote:
> From: Paul Moore <[EMAIL PROTECTED]>
> Date: Fri, 28 Jul 2006 16:09:15 -0400
>
>>Okay. I stated earlier today that I would push a new patchset out to
>>the list this weekend or perhaps today, but in light of this I think
>>I'll wait until I have had a chance to make this cha
From: Paul Moore <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 16:09:15 -0400
> Okay. I stated earlier today that I would push a new patchset out to
> the list this weekend or perhaps today, but in light of this I think
> I'll wait until I have had a chance to make this change which should be
> some
David Miller wrote:
> From: Paul Moore <[EMAIL PROTECTED]>
> Date: Fri, 28 Jul 2006 15:08:44 -0400
>
>>Thanks for your feedback but unless I hear from others that this
>>is a requirement I think I'm going to leave the code as written for the
>>reasons I listed above.
>
> Please switch over to th
From: Paul Moore <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 15:08:44 -0400
> Thanks for your feedback but unless I hear from others that this
> is a requirement I think I'm going to leave the code as written for the
> reasons I listed above.
Please switch over to the scheme which Thomas has sugge
From: Paul Moore <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 14:45:53 -0400
> I'm happy to drop this hook as it *looks* like the MLSXFRM patchset is
> going to make it which has some of the accept hooks I was hoping to get,
> but figured I stood a "snowballs chance in hell" trying to get it in
> so
On Fri, Jul 28, 2006 at 03:08:44PM -0400, Paul Moore ([EMAIL PROTECTED]) wrote:
> > Not a requirement but I would encourage it. Almost all netlink
> > families are using attributes with a few exceptions. We just
> > used to call them rtattr defined in rtnetlink.h before the new
> > api was added. T
Thomas Graf wrote:
> * Paul Moore <[EMAIL PROTECTED]> 2006-07-28 14:39
>
>>It sounds like you main concern is that I'm not using the netlink
>>attribute interfaces, yes? I looked at using those originally but
>>decided not to use them for the following reasons:
>>
>> 1. They are listed as "option
* Paul Moore <[EMAIL PROTECTED]> 2006-07-28 14:39
> It sounds like you main concern is that I'm not using the netlink
> attribute interfaces, yes? I looked at using those originally but
> decided not to use them for the following reasons:
>
> 1. They are listed as "optional" in the documents I r
David Miller wrote:
> From: [EMAIL PROTECTED]
> Date: Mon, 17 Jul 2006 11:52:26 -0400
>>@@ -617,6 +618,8 @@ int inet_accept(struct socket *sock, str
>>
>> sock_graft(sk2, newsock);
>>
>>+ netlbl_socket_inet_accept(sock, newsock);
>>+
>> newsock->state = SS_CONNECTED;
>> err = 0
Thomas Graf wrote:
> * Paul Moore <[EMAIL PROTECTED]> 2006-07-28 13:58
>
>>I'm a little confused by your comment, could you be a bit more
>>specific? Are you basing your comment strictly on the text above? If
>>so, the problem may be my poor excuse for documentation rather then my
>>poor excuse
* Paul Moore <[EMAIL PROTECTED]> 2006-07-28 13:58
> I'm a little confused by your comment, could you be a bit more
> specific? Are you basing your comment strictly on the text above? If
> so, the problem may be my poor excuse for documentation rather then my
> poor excuse for implementation :)
>
Thomas Graf wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> 2006-07-17 11:52
>
>>+ * NetLabel makes use of the Generic NETLINK mechanism as a transport layer
>>to
>>+ * send messages between kernel and user space. The general format of a
>>+ * NetLabel message is shown below:
>>+ *
>>+ * +
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> 2006-07-17 11:52
> + * NetLabel makes use of the Generic NETLINK mechanism as a transport layer
> to
> + * send messages between kernel and user space. The general format of a
> + * NetLabel message is shown below:
> + *
> + * +-+--
From: [EMAIL PROTECTED]
Date: Mon, 17 Jul 2006 11:52:26 -0400
> @@ -617,6 +618,8 @@ int inet_accept(struct socket *sock, str
>
> sock_graft(sk2, newsock);
>
> + netlbl_socket_inet_accept(sock, newsock);
> +
> newsock->state = SS_CONNECTED;
> err = 0;
> release_sock(
Changes to the core network stack to support the NetLabel subsystem. This
includes changes to the IPv4 option handling to support CIPSO labels, and a new
NetLabel hook in inet_accept() to handle NetLabel attributes across accept()
calls done by in-kernel daemons.
Signed-off-by: Paul Moore <[EMAIL
On Friday 14 July 2006 7:34 pm, James Morris wrote:
> On Fri, 14 Jul 2006, [EMAIL PROTECTED] wrote:
> > +static inline void netlbl_put_hdr(unsigned char *buffer,
> > + const u32 msg_type,
> > + const u16 msg_len,
> > +
From: James Morris <[EMAIL PROTECTED]>
Date: Fri, 14 Jul 2006 19:34:20 -0400 (EDT)
> On Fri, 14 Jul 2006, [EMAIL PROTECTED] wrote:
>
> > +static inline void netlbl_put_hdr(unsigned char *buffer,
> > + const u32 msg_type,
> > + const u16 msg_
On Fri, 14 Jul 2006, [EMAIL PROTECTED] wrote:
> +static inline void netlbl_put_hdr(unsigned char *buffer,
> + const u32 msg_type,
> + const u16 msg_len,
> + const u16 msg_flags,
> +
Changes to the core network stack to support the NetLabel subsystem. This
includes changes to the IPv4 option handling to support CIPSO labels, and a new
NetLabel hook in inet_accept() to handle NetLabel attributes across accept()
calls done by in-kernel daemons.
Signed-off-by: Paul Moore <[EMAIL
23 matches
Mail list logo