Eric Paris wrote:
> On Mon, 2006-10-30 at 13:03 -0500, [EMAIL PROTECTED] wrote:
>
>>plain text document attachment (netlabel-sockopts)
>>From: Paul Moore <[EMAIL PROTECTED]>
>>
>>This patch makes two changes to protect applications from either removing or
>>tampering with the CIPSOv4 IP option on a socket. The first is the
>>requirement
>>that applications have the CAP_NET_RAW capability to set an IPOPT_CIPSO option
>>on a socket; this prevents untrusted applications from setting their own
>>CIPSOv4 security attributes on the packets they send. The second change is to
>>SELinux and it prevents applications from setting any IPv4 options when there
>>is an IPOPT_CIPSO option already present on the socket; this prevents
>>applications from removing CIPSOv4 security attributes from the packets they
>>send.
>
>
>>--- net-2.6_sockopt.orig/security/selinux/ss/services.c
>>+++ net-2.6_sockopt/security/selinux/ss/services.c
>>@@ -2682,4 +2682,41 @@ u32 selinux_netlbl_socket_getpeersec_dgr
>>
>> return peer_sid;
>> }
>>+
>>+/**
>>+ * selinux_netlbl_socket_setsockopt - Do not allow users to remove a NetLabel
>>+ * @sock: the socket
>>+ * @level: the socket level or protocol
>>+ * @optname: the socket option name
>>+ *
>>+ * Description:
>>+ * Check the setsockopt() call and if the user is trying to replace the IP
>>+ * options on a socket and a NetLabel is in place for the socket deny the
>>+ * access; otherwise allow the access. Returns zero when the access is
>>+ * allowed, -EACCES when denied, and other negative values on error.
>>+ *
>>+ */
>>+int selinux_netlbl_socket_setsockopt(struct socket *sock,
>>+ int level,
>>+ int optname)
>>+{
>>+ int rc = 0;
>>+ struct inode *inode = SOCK_INODE(sock);
>>+ struct sk_security_struct *sksec = sock->sk->sk_security;
>>+ struct inode_security_struct *isec = inode->i_security;
>>+ struct netlbl_lsm_secattr secattr;
>>+
>>+ mutex_lock(&isec->lock);
>>+ if (level == IPPROTO_IP && optname == IP_OPTIONS &&
>>+ sksec->nlbl_state == NLBL_LABELED) {
>>+ netlbl_secattr_init(&secattr);
>>+ rc = netlbl_socket_getattr(sock, &secattr);
>>+ if (rc == 0 && (secattr.cache || secattr.mls_lvl_vld))
>>+ rc = -EACCES;
>>+ netlbl_secattr_destroy(&secattr);
>>+ }
>>+ mutex_unlock(&isec->lock);
>>+
>>+ return rc;
>>+}
>> #endif /* CONFIG_NETLABEL */
>
> I probably should have ask this a while back but both here and in
> selinux_netlbl_socket_setsid() you are taking the isec->lock. As I
> originally understood the isec->lock it was just supposed to just
> prevent multiple tasks from initializing the isec information
> simultaneously while the isec information could be in an inconsistent
> state. After isec->initialized was set we didn't use the lock any more
> (as typically the only change inside the isec was the ->sid which
> couldn't even be 'in the middle'). I'm wondering what you are hoping to
> protect taking this lock. It doesn't seem like it would hurt anything,
> but i'd like to hear what you see it's purpose as being... (Then again
> it's just as unlikely that I understood what it was being used for
> pre-netlabel)
Fair question. It was discussed a while back on either the SELinux or LSPP
mailing list, I don't have a link handy but I'm sure you could find it with your
favorite search engine (it was discussed back when it was a semaphore); I might
be wrong but I think it was Stephen Smalley that suggested using the isec
semaphore/mutex. Basically, inode_security_struct mutex also protects the
sk_security_struct->nlbl_state field. You will see some cases where the
nlbl_state field is set/checked without holding the mutex but in those cases
only one thread should have access to the sock.
Perhaps at some point it would make sense to protect this with some other
locking mechanism (rcu might make the most sense) but considering the stage that
2.6.19 is at right now I think we should probably leave it alone right now.
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
