From owner-freebsd-security@FreeBSD.ORG Mon Dec 11 20:24:50 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C81D116A416; Mon, 11 Dec 2006 20:24:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3120B43D77; Mon, 11 Dec 2006 19:51:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DC12446E0F; Mon, 11 Dec 2006 14:53:08 -0500 (EST) Date: Mon, 11 Dec 2006 19:53:08 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Craig Edwards In-Reply-To: <4577076A.6080508@winbot.co.uk> Message-ID: <20061211193712.U4227@fledge.watson.org> References: <200612060933.kB69XErN083086@freefall.freebsd.org> <45769654.5050307@freebsd.org> <4576F3A9.9000307@obluda.cz> <4577076A.6080508@winbot.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dan Lukes , freebsd-security@freebsd.org, Colin Percival Subject: Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2006 20:24:50 -0000 On Wed, 6 Dec 2006, Craig Edwards wrote: > Doesn't securelevel completely mitigate this even for root users anyway, if > set? Setting securelevel denies raw access to disk devices and kmem in this > way does it not? Securelevel is intended to protect integrity and not confidentiality, so does not prevent reading, not writing, so is unrelated to this specific issue. I come out generally against releasing an advisory for this issue. In the current security model, members of the operator group have a high level of privilege in the system, as they can: - Read from partitions used for file system storage, including delete and unallocated space. - Read from swap partitions, allowing access to both kernel dumps and paged out process data. Since they can generally force paging on systems with swap, this effectively means read access to most process memory, as well as the pageable memory associated with kernel pipe IPC. - Directly interface with the many controllers and other devices via device drivers granting read or write access to the operator group. I think releasing a security advisory for this problem offers a false promise: we don't promise to protect kernel data or the kernel from the operator user, and releasing an advisory suggests we do. I think it's very likely that other device drivers On the other hand, I think we should be thinking about replacements for our current notion of an operator group. For example, should we have shutdown/dump/etc be setgid operator for access to disk, but authorize use based on membership of another group, which would avoid granting device I/O privileges to members of this new operator group? Likewise, the right to shutdown a system should not necessarily correspond with the right to back up any mounted file system. Thoughts on the best thing to do here would be most welcome. Mac OS X, for example, has a notion of a user space policy file in /etc that is checked by various setuid/setgid tools to see whether the invoking user has a specific high level privilege. The distinction between high level and low level there, btw, is that a low level privilege is the privilege as represented with respect to the kernel (reboot, read raw disk, etc) and the high level privilege is the use of privilege provided and interpretted by a privilege-elevated (setuid/setgid) program (the right to shutdown, the right to back up, etc). Obviously, the program implementing the service has to have significant low level privilege, but it also gates rights due to its interpretation of a higher level notion of privilege and authorization. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-security@FreeBSD.ORG Fri Dec 15 05:32:39 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E199716A412 for ; Fri, 15 Dec 2006 05:32:39 +0000 (UTC) (envelope-from koziol@hdfgroup.org) Received: from mail45.opentransfer.com (mail45.opentransfer.com [71.18.111.238]) by mx1.FreeBSD.org (Postfix) with SMTP id B858643CA3 for ; Fri, 15 Dec 2006 05:30:58 +0000 (GMT) (envelope-from koziol@hdfgroup.org) Received: (qmail 19757 invoked by uid 399); 15 Dec 2006 05:32:33 -0000 Received: from unknown (HELO ?192.168.1.102?) (66.158.169.70) by mail45.opentransfer.com with SMTP; 15 Dec 2006 05:32:33 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) To: freebsd-security@freebsd.org Message-Id: <5C883CE5-2A0A-4D7D-BE47-5B4EEFED18B1@hdfgroup.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-93-1022581317; protocol="application/pkcs7-signature" From: Quincey Koziol Date: Thu, 14 Dec 2006 23:34:17 -0600 X-Mailer: Apple Mail (2.752.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems using gssapi authentication from FreeBSD to Linux machines X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2006 05:32:40 -0000 --Apple-Mail-93-1022581317 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, I'm really struggling with getting Kerberos authentication to work between a FreeBSD host and a Linux host. I'm using the latest 6- STABLE code on the FreeBSD box, I've got forwardable Kerberos tokens (verified with "klist -f") and Kerberos and ssh are working fine in all other ways, but I can't get the Linux box to accept the Kerberos ticket as authentication from the FreeBSD machine. The Linux box accepts Kerberos credentials from other Linux machines and I can use ssh on the FreeBSD machine to connect to itself with Kerberos credentials (i.e. not required to type my password). This leads me to believe that either the protocol for forwarding the Kerberos credentials is different between the two machines or there's another minor tweak I need to make to the ssh_config file on the FreeBSD machine. One other difference is that the Linux box is running OpenSSH 3.9p1 and the FreeBSD box is running OpenSSH 4.5p1. Here's my ssh_config from the FreeBSD machine: # $OpenBSD: ssh_config,v 1.22 2006/05/29 12:56:33 dtucker Exp $ # $FreeBSD: src/crypto/openssh/ssh_config,v 1.27.2.4 2006/11/11 00:51:28 des Exp $ # This is the ssh client system-wide configuration file. See # ssh_config(5) for more information. This file provides defaults for # users, and the values can be changed in per-user configuration files # or on the command line. # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Site-wide defaults for some commonly used options. For a comprehensive # list of available options, their meanings and defaults, please see the # ssh_config(5) man page. # Host * # ForwardAgent no # ForwardX11 no # RhostsRSAAuthentication no # RSAAuthentication yes # PasswordAuthentication yes # HostbasedAuthentication no # GSSAPIAuthentication no # GSSAPIDelegateCredentials no # BatchMode no # CheckHostIP no # AddressFamily any # ConnectTimeout 0 # StrictHostKeyChecking ask # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # Port 22 # Protocol 2,1 # Cipher 3des # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc # EscapeChar ~ # Tunnel no # TunnelDevice any:any # PermitLocalCommand no # VersionAddendum FreeBSD-20061110 # Add kerberos ticket forwarding # QAK - 12/13/06 Host * GSSAPIAuthentication yes GSSAPIDelegateCredentials yes # If this option is set to yes then the remote X11 clients will have full access # to the local X11 display. As virtually no X11 client supports the untrusted # mode correctly we set this to yes. ForwardX11Trusted yes Here's the log of "ssh -v -v -v" connecting from the FreeBSD box to the Linux box: (you can see that the login succeeds because I typed in my password) OpenSSH_4.5p1 FreeBSD-20061110, OpenSSL 0.9.7e-p1 25 Oct 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to kagiso.hdfgroup.uiuc.edu [192.17.35.93] port 22. debug1: Connection established. debug1: identity file /home/koziol/.ssh/identity type -1 debug1: identity file /home/koziol/.ssh/id_rsa type -1 debug1: identity file /home/koziol/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange- sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14- sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128- ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128- ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 135/256 debug2: bits set: 497/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/koziol/.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug1: Host 'kagiso.hdfgroup.uiuc.edu' is known and matches the DSA host key. debug1: Found key in /home/koziol/.ssh/known_hosts:2 debug2: bits set: 526/1024 debug1: ssh_dss_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/koziol/.ssh/identity (0x0) debug2: key: /home/koziol/.ssh/id_rsa (0x0) debug2: key: /home/koziol/.ssh/id_dsa (0x0) debug1: Authentications that can continue: gssapi-with-mic,password debug3: start over, passed a different list gssapi-with-mic,password debug3: preferred gssapi-with-mic,publickey,keyboard- interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentications that can continue: gssapi-with-mic,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,keyboard-interactive,password debug3: authmethod_is_enabled password debug1: Next authentication method: password debug3: packet_send2: adding 48 (len 62 padlen 18 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug2: fd 5 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 8 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 255 debug3: tty_make_modes: 7 255 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 11 25 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 17 20 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 0 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 1 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 1 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 1 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Last login: Thu Dec 14 22:54:25 2006 from duty.hdfgroup.uiuc.edu **** Message of the Day **** Kagiso has backup running on /, /home and /mnt/hdf. Email me restore requests. In your mail, specify the complete pathname of the files you need recovery. -AKC- 2006/07/17. Kagiso /home is restored to as of November 16th, 2AM. Pleaes check your area to see if you miss some files or detect some errors. Email hdfadmin if you have problem. -AKC- 2006/11/19. (You can read this message again by "cat /etc/motd".) [koziol@kagiso ~]$ exit logout debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 6 c -1 debug1: fd 1 clearing O_NONBLOCK debug3: fd 2 is not O_NONBLOCK Connection to kagiso.hdfgroup.uiuc.edu closed. debug1: Transferred: stdin 0, stdout 0, stderr 48 bytes in 9.3 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 5.1 debug1: Exit status 0 And here's the log of another Linux box connecting to the Linux machine: (which succeeds using the Kerberos ticket) OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to kagiso [192.17.35.93] port 22. debug1: Connection established. debug1: identity file /home/koziol/.ssh/identity type -1 debug1: identity file /home/koziol/.ssh/id_rsa type -1 debug1: identity file /home/koziol/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128- ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128- ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 133/256 debug2: bits set: 522/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/koziol/.ssh/known_hosts debug3: check_host_in_hostfile: match line 3 debug3: check_host_in_hostfile: filename /home/koziol/.ssh/known_hosts debug3: check_host_in_hostfile: match line 3 debug1: Host 'kagiso' is known and matches the RSA host key. debug1: Found key in /home/koziol/.ssh/known_hosts:3 debug2: bits set: 501/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/koziol/.ssh/identity ((nil)) debug2: key: /home/koziol/.ssh/id_rsa ((nil)) debug2: key: /home/koziol/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: gssapi-with-mic,password debug3: start over, passed a different list gssapi-with-mic,password debug3: preferred gssapi-with-mic,publickey,keyboard- interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentication succeeded (gssapi-with-mic). debug2: fd 5 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 8 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 0 debug3: tty_make_modes: 7 0 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 0 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 37 0 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 1 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 1 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 52 0 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 1 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 71 0 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Last login: Thu Dec 14 23:12:03 2006 from duty.hdfgroup.uiuc.edu **** Message of the Day **** Kagiso has backup running on /, /home and /mnt/hdf. Email me restore requests. In your mail, specify the complete pathname of the files you need recovery. -AKC- 2006/07/17. Kagiso /home is restored to as of November 16th, 2AM. Pleaes check your area to see if you miss some files or detect some errors. Email hdfadmin if you have problem. -AKC- 2006/11/19. (You can read this message again by "cat /etc/motd".) [koziol@kagiso ~]$ exit logout debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 6 c -1 debug1: fd 1 clearing O_NONBLOCK debug3: fd 2 is not O_NONBLOCK Connection to kagiso closed. debug1: Transferred: stdin 0, stdout 0, stderr 30 bytes in 4.9 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 6.2 debug1: Exit status 0 The main difference I can see is that the FreeBSD log has this: debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentications that can continue: gssapi-with-mic,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password And the Linux log has this: debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentication succeeded (gssapi-with-mic). Any ideas what could be causing the ssh on FreeBSD to "not send a packet"? Thanks, Quincey Koziol koziol@hdfgroup.org --Apple-Mail-93-1022581317-- From owner-freebsd-security@FreeBSD.ORG Fri Dec 15 07:51:49 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF79F16A583 for ; Fri, 15 Dec 2006 07:51:49 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [80.253.10.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DD2C43CA5 for ; Fri, 15 Dec 2006 07:50:09 +0000 (GMT) (envelope-from bsam@ipt.ru) Received: from doc.sem.ipt.ru ([192.168.12.1] helo=ipt.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1Gv7r9-0006gB-5i; Fri, 15 Dec 2006 10:51:47 +0300 Received: from bsam by ipt.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gv7sF-0004S6-PK; Fri, 15 Dec 2006 10:52:55 +0300 To: Quincey Koziol References: <5C883CE5-2A0A-4D7D-BE47-5B4EEFED18B1@hdfgroup.org> From: Boris Samorodov Date: Fri, 15 Dec 2006 10:52:55 +0300 In-Reply-To: <5C883CE5-2A0A-4D7D-BE47-5B4EEFED18B1@hdfgroup.org> (Quincey Koziol's message of "Thu, 14 Dec 2006 23:34:17 -0600") Message-ID: <48779656@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-security@freebsd.org Subject: Re: Problems using gssapi authentication from FreeBSD to Linux machines X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2006 07:51:49 -0000 On Thu, 14 Dec 2006 23:34:17 -0600 Quincey Koziol wrote: > Hi all, > I'm really struggling with getting Kerberos authentication to > work between a FreeBSD host and a Linux host. I'm using the latest > 6- > STABLE code on the FreeBSD box, I've got forwardable Kerberos tokens > (verified with "klist -f") and Kerberos and ssh are working fine in > all other ways, but I can't get the Linux box to accept the Kerberos > ticket as authentication from the FreeBSD machine. The Linux box > accepts Kerberos credentials from other Linux machines and I can use > ssh on the FreeBSD machine to connect to itself with Kerberos > credentials (i.e. not required to type my password). This leads me > to believe that either the protocol for forwarding the Kerberos > credentials is different between the two machines or there's another > minor tweak I need to make to the ssh_config file on the FreeBSD > machine. One other difference is that the Linux box is running > OpenSSH 3.9p1 and the FreeBSD box is running OpenSSH 4.5p1. This difference should not be a problem. > Here's my ssh_config from the FreeBSD machine: > # $OpenBSD: ssh_config,v 1.22 2006/05/29 12:56:33 dtucker Exp $ > # $FreeBSD: src/crypto/openssh/ssh_config,v 1.27.2.4 2006/11/11 > 00:51:28 des Exp $ > # This is the ssh client system-wide configuration file. See > # ssh_config(5) for more information. This file provides defaults for > # users, and the values can be changed in per-user configuration files > # or on the command line. > # Configuration data is parsed as follows: > # 1. command line options > # 2. user-specific file > # 3. system-wide file > # Any configuration value is only changed the first time it is set. > # Thus, host-specific definitions should be at the beginning of the > # configuration file, and defaults at the end. > # Site-wide defaults for some commonly used options. For a > comprehensive > # list of available options, their meanings and defaults, please see the > # ssh_config(5) man page. > # Host * > # ForwardAgent no > # ForwardX11 no > # RhostsRSAAuthentication no > # RSAAuthentication yes > # PasswordAuthentication yes > # HostbasedAuthentication no > # GSSAPIAuthentication no > # GSSAPIDelegateCredentials no > # BatchMode no > # CheckHostIP no > # AddressFamily any > # ConnectTimeout 0 > # StrictHostKeyChecking ask > # IdentityFile ~/.ssh/identity > # IdentityFile ~/.ssh/id_rsa > # IdentityFile ~/.ssh/id_dsa > # Port 22 > # Protocol 2,1 > # Cipher 3des > # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128- > cbc,arcfour,aes192-cbc,aes256-cbc > # EscapeChar ~ > # Tunnel no > # TunnelDevice any:any > # PermitLocalCommand no > # VersionAddendum FreeBSD-20061110 > # Add kerberos ticket forwarding > # QAK - 12/13/06 > Host * May be it's paranoid but I prefer to use more strict values here, i.e. *.my.domain. This may prevent sending my credentials to hosts if I incidentally misspell a command. > GSSAPIAuthentication yes > GSSAPIDelegateCredentials yes > # If this option is set to yes then the remote X11 clients will have > full access > # to the local X11 display. As virtually no X11 client supports the > untrusted > # mode correctly we set this to yes. > ForwardX11Trusted yes [logs skipped] > The main difference I can see is that the FreeBSD log has this: > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Delegating credentials > debug1: Delegating credentials > debug1: Authentications that can continue: gssapi-with-mic,password > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > And the Linux log has this: > debug1: Next authentication method: gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Delegating credentials > debug1: Delegating credentials > debug1: Authentication succeeded (gssapi-with-mic). > Any ideas what could be causing the ssh on FreeBSD to "not > send a packet"? Seems that the Linux host doesn't accept credentials. Do you have an access to this box? If yes, run sshd with verbose debug ("ddd") at different port (say, "-p 1000") and then try to connect to this host via ssh from FreeBSD host. Look at debugging log for the connection details. HTH WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-security@FreeBSD.ORG Sat Dec 16 15:07:23 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9B6A16A403 for ; Sat, 16 Dec 2006 15:07:23 +0000 (UTC) (envelope-from jurjenm@stack.nl) Received: from mx1.stack.nl (meestal.stack.nl [131.155.140.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7085743C9D for ; Sat, 16 Dec 2006 15:07:23 +0000 (GMT) (envelope-from jurjenm@stack.nl) Received: by mx1.stack.nl (Postfix, from userid 65534) id 299454B2F1; Sat, 16 Dec 2006 16:07:22 +0100 (CET) X-Spam-DCC: CollegeOfNewCaledonia: snail.stack.nl 1189; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on snail.stack.nl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Relay-Country: NL Received: from snhmib (a62-251-106-27.adsl.xs4all.nl [62.251.106.27]) by mailhost.stack.nl (Postfix) with ESMTP id CC0834B2E0 for ; Sat, 16 Dec 2006 16:07:19 +0100 (CET) Received: by snhmib (sSMTP sendmail emulation); Sat, 16 Dec 2006 16:06:50 +0100 From: "Jurjen Middendorp" Date: Sat, 16 Dec 2006 16:06:50 +0100 To: freebsd-security@freebsd.org Message-ID: <20061216150650.GA876@jurjenm.stack.nl> Mail-Followup-To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: ipfw: did i forget anything? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2006 15:07:24 -0000 Hello, i hope this is the right list! I tried making a firewall for my laptop..it wasn't as terribly difficult as i thought it would be but i'm not sure if i forgot anything. And things can always be done better :) I'm not sure what i should've put under incoming connections... what i have put there now is pretty useless because the default is to deny, but should i accept any incoming connections that don't match the dynamic rules? I just want to be able to surf the internet without too much trouble and send e-mail and pretty much deny everything else. If someone would have the time to have a quick look at this to see if there's anything wrong with it i would really appreciate it! Bye, jurjen. ps. here is my ruleset: #!/bin/sh ipfw -q flush cmd="ipfw -q add" ks="keep-state" oif="ath0" #setup the loopback $cmd 001 allow all from any to any via lo0 $cmd 002 deny all from any to 127.0.0.0/8 $cmd 003 deny ip from 127.0.0.0/8 to any #check state of incoming packets $cmd 010 check-state #### # Outgoing #allow outgoing connections to internetsites, ssh sites # webservers and stack. (keep-state) #to stack (student computer organisation thing) $cmd 020 allow all from me to 131.155.0.0/16 via $oif $ks #allow ssh $cmd 021 allow all from me to any 22 $ks #internet sites: $cmd 032 allow tcp from me to any 80 $ks #https $cmd 033 allow tcp from me to any 443 $ks #gopher $cmd 034 allow tcp from me to any 70 $ks #other e-mail #pop $cmd 040 allow tcp from me to any 110 $ks #imap $cmd 041 allow tcp from me to any 143 $ks #allow dns queries $cmd 050 allow udp from me to any 53 $ks #allow ntp (?) queries $cmd 051 allow udp from me to any 123 $ks #i can send icmp myself $cmd 060 allow icmp from me to any out via $oif $ks #but others can't $cmd 061 deny icmp from any to me # #root can do anything $cmd 070 allow tcp from me to any out via $oif setup $ks uid root #log other outgoing packets $cmd 071 deny log all from any to any out via $oif #### # Incoming #deny incoming from private networks $cmd 100 deny all from 192.168.0.0/16 to any in via $oif #RFC 1918 $cmd 101 deny all from 172.16.0.0/16 to any in via $oif #RFC 1918 $cmd 102 deny all from 10.0.0.0/8 to any in via $oif $cmd 105 deny all from 169.254.0.0/16 to any in via $oif #DHCP auto $cmd 106 deny all from 192.0.2.0/24 to any in via $oif #reserved $cmd 108 deny all from 192.168.0.0/16 to any in via $oif #D & E class # multicast #block samba stuff $cmd 120 deny tcp from any to me 137 in via $oif $cmd 121 deny tcp from any to me 138 in via $oif $cmd 122 deny tcp from any to me 139 in via $oif #log ACK packets that didn't match the dynamic ruleset $cmd 130 deny log all from any to any established in via $oif #Now log some stuff in case i did something wrong $cmd 999 deny log any to me From owner-freebsd-security@FreeBSD.ORG Sat Dec 16 15:20:09 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2715D16A403 for ; Sat, 16 Dec 2006 15:20:09 +0000 (UTC) (envelope-from jurjenm@stack.nl) Received: from mx1.stack.nl (meestal.stack.nl [131.155.140.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DD7143C9E for ; Sat, 16 Dec 2006 15:20:08 +0000 (GMT) (envelope-from jurjenm@stack.nl) Received: by mx1.stack.nl (Postfix, from userid 65534) id C59A74AFE1; Sat, 16 Dec 2006 16:20:07 +0100 (CET) X-Spam-DCC: CollegeOfNewCaledonia: snail.stack.nl 1189; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on snail.stack.nl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.5 X-Spam-Relay-Country: NL Received: from snhmib (a62-251-106-27.adsl.xs4all.nl [62.251.106.27]) by mailhost.stack.nl (Postfix) with ESMTP id C283A4AEF2 for ; Sat, 16 Dec 2006 16:20:04 +0100 (CET) Received: by snhmib (sSMTP sendmail emulation); Sat, 16 Dec 2006 16:19:35 +0100 From: "Jurjen Middendorp" Date: Sat, 16 Dec 2006 16:19:35 +0100 To: freebsd-security@freebsd.org Message-ID: <20061216151935.GA1380@jurjenm.stack.nl> Mail-Followup-To: freebsd-security@freebsd.org References: <20061216150650.GA876@jurjenm.stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216150650.GA876@jurjenm.stack.nl> User-Agent: Mutt/1.4.2.2i Subject: Re: ipfw: did i forget anything? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2006 15:20:09 -0000 I'm sorry i think this is the wrong list feel free to delete these messages!