Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.
Hello. Thank you for your comment. James Morris wrote: > I'm guessing you need this to determine the receiving process, rather than > the socket (which is available via security_sock_rcv_skb()). Use of security_sock_rcv_skb() was discussed at http://lkml.org/lkml/2007/8/28/74 , and answer is at http://lkml.org/lkml/2007/10/2/56 . > If so, is this to interactively determine from the user or admin whether > the packet should be accepted/denied for the receiving process? Yes, it is to determine whether the packet should be accepted/denied based on the receiving process (like what anti-virus software's firewall does). Regards. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.
On Tue, 2 Oct 2007, Kentaro Takeda wrote:
> --- linux-2.6.orig/net/core/datagram.c2007-10-02 11:11:51.0
> +0900
> +++ linux-2.6/net/core/datagram.c 2007-10-02 11:26:23.0 +0900
> @@ -55,6 +55,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Is a socket 'connection oriented' ?
> @@ -178,6 +179,27 @@ struct sk_buff *skb_recv_datagram(struct
> } else
> skb = skb_dequeue(>sk_receive_queue);
>
> + error = security_post_recv_datagram(sk, skb, flags);
> + if (error) {
> + unsigned long cpu_flags;
> +
> + if (!(flags & MSG_PEEK))
> + goto no_peek;
> +
> + spin_lock_irqsave(>sk_receive_queue.lock,
> + cpu_flags);
> + if (skb == skb_peek(>sk_receive_queue)) {
> + __skb_unlink(skb,
> + >sk_receive_queue);
> + atomic_dec(>users);
> + }
> + spin_unlock_irqrestore(>sk_receive_queue.lock,
> +cpu_flags);
> +no_peek:
> + skb_free_datagram(sk, skb);
> + goto no_packet;
> + }
> +
> if (skb)
> return skb;
I'm guessing you need this to determine the receiving process, rather than
the socket (which is available via security_sock_rcv_skb()).
If so, is this to interactively determine from the user or admin whether
the packet should be accepted/denied for the receiving process?
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.
Hello. James Morris wrote: > Why do you need racy unlocked versions, in addition to the existing > security_task_kill() hook which is called safely via > check_kill_permission() ? TOMOYO Linux provides "delayed enforcing mode" which allows administrator judge interactively for requests that violated policy. Sometimes, especially after updating software packages, irregular behavior arise. So, the administrator prepares for such irregular behavior by invoking "ccs-queryd" userland program. The "ccs-queryd" prints the contents of policy violation and asks the administrator whether to grant the request that violated policy. This can reduce the possibility of "restarting process failed due to permission denied". Thus, security_task_kill() which is called with tasklist_lock held is not what TOMOYO Linux wants. I know this approach is racy, but TOMOYO Linux wants these unlocked versions to avoid failure due to permission denial caused by MAC's policy. Regards. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.
On Tue, 2 Oct 2007, Kentaro Takeda wrote: > LSM expansion for TOMOYO Linux. > > LSM hooks for sending signal: >* task_kill_unlocked is added in sys_kill >* task_tkill_unlocked is added in sys_tkill >* task_tgkill_unlocked is added in sys_tgkill Why do you need racy unlocked versions, in addition to the existing security_task_kill() hook which is called safely via check_kill_permission() ? - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.
On Tue, 2 Oct 2007, Kentaro Takeda wrote: LSM expansion for TOMOYO Linux. LSM hooks for sending signal: * task_kill_unlocked is added in sys_kill * task_tkill_unlocked is added in sys_tkill * task_tgkill_unlocked is added in sys_tgkill Why do you need racy unlocked versions, in addition to the existing security_task_kill() hook which is called safely via check_kill_permission() ? - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.
Hello. James Morris wrote: Why do you need racy unlocked versions, in addition to the existing security_task_kill() hook which is called safely via check_kill_permission() ? TOMOYO Linux provides delayed enforcing mode which allows administrator judge interactively for requests that violated policy. Sometimes, especially after updating software packages, irregular behavior arise. So, the administrator prepares for such irregular behavior by invoking ccs-queryd userland program. The ccs-queryd prints the contents of policy violation and asks the administrator whether to grant the request that violated policy. This can reduce the possibility of restarting process failed due to permission denied. Thus, security_task_kill() which is called with tasklist_lock held is not what TOMOYO Linux wants. I know this approach is racy, but TOMOYO Linux wants these unlocked versions to avoid failure due to permission denial caused by MAC's policy. Regards. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.
On Tue, 2 Oct 2007, Kentaro Takeda wrote:
--- linux-2.6.orig/net/core/datagram.c2007-10-02 11:11:51.0
+0900
+++ linux-2.6/net/core/datagram.c 2007-10-02 11:26:23.0 +0900
@@ -55,6 +55,7 @@
#include net/checksum.h
#include net/sock.h
#include net/tcp_states.h
+#include linux/security.h
/*
* Is a socket 'connection oriented' ?
@@ -178,6 +179,27 @@ struct sk_buff *skb_recv_datagram(struct
} else
skb = skb_dequeue(sk-sk_receive_queue);
+ error = security_post_recv_datagram(sk, skb, flags);
+ if (error) {
+ unsigned long cpu_flags;
+
+ if (!(flags MSG_PEEK))
+ goto no_peek;
+
+ spin_lock_irqsave(sk-sk_receive_queue.lock,
+ cpu_flags);
+ if (skb == skb_peek(sk-sk_receive_queue)) {
+ __skb_unlink(skb,
+ sk-sk_receive_queue);
+ atomic_dec(skb-users);
+ }
+ spin_unlock_irqrestore(sk-sk_receive_queue.lock,
+cpu_flags);
+no_peek:
+ skb_free_datagram(sk, skb);
+ goto no_packet;
+ }
+
if (skb)
return skb;
I'm guessing you need this to determine the receiving process, rather than
the socket (which is available via security_sock_rcv_skb()).
If so, is this to interactively determine from the user or admin whether
the packet should be accepted/denied for the receiving process?
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 14/15](repost) LSM expansion for TOMOYO Linux.
Hello. Thank you for your comment. James Morris wrote: I'm guessing you need this to determine the receiving process, rather than the socket (which is available via security_sock_rcv_skb()). Use of security_sock_rcv_skb() was discussed at http://lkml.org/lkml/2007/8/28/74 , and answer is at http://lkml.org/lkml/2007/10/2/56 . If so, is this to interactively determine from the user or admin whether the packet should be accepted/denied for the receiving process? Yes, it is to determine whether the packet should be accepted/denied based on the receiving process (like what anti-virus software's firewall does). Regards. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
