1 7574 Jan Copyright 2008 Sun Microsystems, Inc. All rights reserved. 2 0 stevel Use is subject to license terms. 3 0 stevel 4 0 stevel Sun's Alternative "Privilege Separation" for OpenSSH 5 0 stevel 6 0 stevel 7 0 stevel Table of Contents 8 0 stevel 9 0 stevel 1. Introduction 10 0 stevel 2. What is "Privilege?" 11 0 stevel 3. Analysis of the SSH Protocols 12 0 stevel 3.1. Privileged Resources, Operations, in the SSH Protocols 13 0 stevel 4. OpenSSH's Privilege Separation 14 0 stevel 5. SUNWssh's Alternative Privilege Separation 15 0 stevel 6. Comparison of the OpenSSH and SUNWssh PrivSep Models 16 0 stevel 7. Future Directions 17 0 stevel 8. Guide to the AltPrivSep Source Code 18 0 stevel A. References 19 0 stevel 20 0 stevel 21 0 stevel 22 0 stevel 23 0 stevel 24 0 stevel 1. Introduction 25 0 stevel 26 0 stevel Implementations of SSH servers require some degree of privilege in 27 0 stevel order to function properly. Often such implementations retain such 28 0 stevel privilege throughout normal operation even while users are logged 29 0 stevel in. This means that vulnerabilities in the implementation of the 30 0 stevel protocols can be exploited in such ways as to escalate the privilege 31 0 stevel that would normally be accorded to mer-mortal users. 32 0 stevel 33 0 stevel The OpenSSH team introduced support for "privilege separation" in 34 0 stevel the OpenSSH ssh server some years ago to minimize the extent of 35 0 stevel extant, undiscovered vulnerabilities in the OpenSSH server source 36 0 stevel code. The basic concept is to have a multi-process server 37 0 stevel implementation where one process, the "monitor" is privileged and 38 0 stevel implements a smaller protocol than the ssh protocols, and thus is, 39 0 stevel hopefully, less likely to sport exploitable security bugs. 40 0 stevel 41 0 stevel The ssh team at Sun agrees with the basic OpenSSH privilege 42 0 stevel separation concept, but disagrees with its design. 43 0 stevel 44 0 stevel Here we present our alternative to the OpenSSH design. We begin 45 0 stevel with the question of just what is "privilege" and follow on with an 46 0 stevel analysis of the SSH protocols vis-a-vis privilege. Then we briefly 47 0 stevel describe the OpenSSH model, followed by an exposition of our 48 0 stevel alternative model. 49 0 stevel 50 0 stevel 51 0 stevel 2. What is "Privilege?" 52 0 stevel 53 0 stevel Privilege, in a traditional Unix sense, is that which the "root" 54 0 stevel user can do that other users cannot directly do. In Solaris 10 55 0 stevel there is a new approach to this sort of privilege with the aim of 56 0 stevel running much of the operating system with the Least Privilege 57 0 stevel required; root's privilege is broken down into many privileges and 58 0 stevel these are managed through privilege sets. We won't go into the 59 0 stevel details of Solaris 10's Least Privilege facility here. 60 0 stevel 61 0 stevel But privilege is also access to data and resources that can be used 62 0 stevel to escalate the privilege of those who have access to them. For 63 0 stevel example: secret, or private cryptographic keys used in 64 0 stevel authentication. Network security typically requires the use of 65 0 stevel cryptographic keys for authentication. 66 0 stevel 67 0 stevel 68 0 stevel 3. Analysis of the SSH Protocols 69 0 stevel 70 0 stevel There are two or, rather three SSH protocols: 71 0 stevel 72 0 stevel - version 1 73 0 stevel - version 1.5 74 0 stevel - version 2 75 0 stevel 76 0 stevel Version 1 and 1.5 are much the same, from our point of view; version 77 0 stevel 2 is significantly different from the other two. 78 0 stevel 79 0 stevel Familiarity by the reader with the specifications for these 80 0 stevel protocols is not assumed, but would be beneficial to the reader. 81 0 stevel 82 0 stevel Quite roughly, these protocols consist of the following: 83 0 stevel 84 0 stevel a) initial version exchange (for protocol version negotiation) 85 0 stevel b) a binary encoding of message data 86 0 stevel c) message syntaxes for the protocols' messages 87 0 stevel d) specifications on use of cryptography for transport 88 0 stevel privacy (encryption) and integrity protection 89 0 stevel e) a key exchange protocol (which also authenticates servers to 90 0 stevel clients) 91 0 stevel f) a protocol for user authentication 92 0 stevel g) a session protocol 93 0 stevel h) a re-keying protocol (v2-only) 94 0 stevel 95 0 stevel Some of these parts of the ssh protocols are quite complex, some 96 0 stevel quite straightforward. Altogether implementation of the ssh 97 0 stevel protocols requires a source code base of significant size. 98 0 stevel 99 0 stevel The OpenSSH implementation relies on OpenSSL for cryptographic 100 0 stevel service, on libz for compression service and miscellaneous other 101 0 stevel libraries. Besides these OpenSSH consists of several tens of 102 0 stevel thousands of lines of source code in C. 103 0 stevel 104 0 stevel SUNWssh is based on OpenSSH, so it is comparable in size and 105 0 stevel complexity to OpenSSH. 106 0 stevel 107 0 stevel There is, then, plenty of space for security bugs in the OpenSSH, 108 0 stevel and, therefore, also in the SUNWssh source code bases. 109 0 stevel 110 0 stevel The OpenSSH team designed and implemented a "privilege separation" 111 0 stevel feature in their ssh server to reduce the risk that a security bug 112 0 stevel in OpenSSH could be successfully exploited and an attacker's 113 0 stevel privilege escalated. 114 0 stevel 115 0 stevel 116 0 stevel 3.1. Privileged Resources, Operations, in the SSH Protocols 117 0 stevel 118 0 stevel What privileges does an SSH server need then? 119 0 stevel 120 0 stevel Observation with Solaris 10's ppriv(1) and truss(1) commands as well 121 0 stevel as analysis of the ssh protocols leads to conclude as follows. 122 0 stevel 123 0 stevel No privilege or privileged resources are needed to implement the 124 0 stevel parts (a)-(d) mentioned in section 3. 125 0 stevel 126 0 stevel 127 1789 jp161948 For key exchange and server authentication (e) an ssh server requires: 128 0 stevel 129 0 stevel - Access to the host's ssh private keys. 130 0 stevel 131 0 stevel - Access to the host's GSS-API acceptor credentials. [SSHv2-only] 132 1789 jp161948 133 1789 jp161948 134 1789 jp161948 An ssh server requires practically all privileges for user 135 1789 jp161948 authentication (f) (at least PAM does), particularly 136 1789 jp161948 PRIV_PROC_SETID, for logging the user in. 137 0 stevel 138 0 stevel 139 0 stevel Post-authentication an ssh server requires the following privileges: 140 0 stevel 141 0 stevel - Those required for auditing a user's subsequent logout. 142 0 stevel 143 0 stevel That is, PRIV_PROC_AUDIT. 144 0 stevel 145 0 stevel 146 0 stevel - Those required for record keeping (i.e., utmpx/wtmpx logging). 147 0 stevel 148 0 stevel That is, either open file descriptor for those files or 149 0 stevel PRIV_FILE_DAC_WRITE or otherwise access to those files, perhaps 150 0 stevel through a special user id or group id which would be granted 151 0 stevel write access through the ACLs on those files. 152 0 stevel 153 0 stevel Since SSHv2 allows clients to open many channels with 154 0 stevel pseudo-terminals a server may need to open and close utmpx/wtmpx 155 0 stevel records multiple times in the lifetime of an SSHv2 connection. 156 0 stevel 157 0 stevel 158 0 stevel - Those required for accessing the host's ssh private keys for 159 0 stevel SSHv2 re-keying. [SSHv2-only] 160 0 stevel 161 0 stevel These keys can be (and are) loaded at server startup time, 162 0 stevel requiring PRIV_FILE_DAC_READ, or access through file ACLs, at 163 0 stevel that time, but not thence. 164 0 stevel 165 0 stevel 166 0 stevel - Those required for accessing the host's GSS-API acceptor 167 0 stevel credentials for SSHv2 re-keying. 168 0 stevel 169 0 stevel These credentials may require a large set of privileges. The 170 0 stevel Solaris 10 Kerberos V GSS-API mechanism, for example, requires 171 0 stevel PRIV_FILE_DAC_READ (for access to the system keytab) and 172 0 stevel PRIV_FILE_DAC_WRITE (for access to the Kerberos V replay cache). 173 0 stevel 174 0 stevel 175 0 stevel It is worth pointing out that because of a wrinkle in the 176 0 stevel specification of the SSHv2 protocol and various implementations, 177 0 stevel access to a host's ssh private keys can allow one not only to 178 0 stevel impersonate the host as a server (which is, in practice, difficult), 179 0 stevel but also to impersonate the host as a client (which is quite easy to 180 0 stevel do) using "hostbased" user authentication. 181 0 stevel 182 0 stevel It is entirely possible to have one-process server implementation 183 0 stevel that drops most privileges and access to privileged resources after 184 0 stevel user authentication succeeds. Such an implementation would make 185 0 stevel some privileges, such as PRIV_PROC_SETID, available to any attacker 186 0 stevel that successfully exploited a security bug in the ssh server. 187 0 stevel 188 0 stevel But such an implementation would also have to retain access to 189 0 stevel resources needed for authenticating the server, which, as described 190 0 stevel above, can be used to impersonate the server, in some cases with 191 0 stevel ease. 192 0 stevel 193 0 stevel 194 7574 Jan 4. OpenSSH's Privilege Separation 195 0 stevel 196 0 stevel The OpenSSH privilege separation model is quite complex. 197 0 stevel 198 0 stevel It consists of a monitor, which retains all privileges and access to 199 0 stevel privileged resources, and two processes which run with much less 200 0 stevel privilege: one process running as a special user, "sshd," for 201 0 stevel hosting all phases of the SSH protocols up to and including 202 0 stevel authentication, and one process running as the actual user that logs 203 0 stevel in and which hosts all phases of the SSH protocols post-user- 204 0 stevel authentication. 205 0 stevel 206 0 stevel The monitor and its companion processes speak a private protocol 207 0 stevel over IPC. This protocol is intended to be smaller and simpler than 208 0 stevel the SSH wire protocols. 209 0 stevel 210 0 stevel In practice the OpenSSH monitor protocols relating to user 211 0 stevel authentication are neither smaller nor simpler than the SSH user 212 0 stevel authentication protocols; and though they are different they also 213 0 stevel transport much the same data, including RSA/DSA signatures, 214 0 stevel usernames, PAM conversations, and GSS-API context and MIC tokens. 215 0 stevel 216 0 stevel The key exchange protocols have been broken down into their 217 0 stevel essentials and the monitor serves only services such as signing 218 0 stevel server replies with private host keys. 219 0 stevel 220 0 stevel Note also that the OpenSSH monitor protocol uses the same encodings 221 0 stevel as the SSH protocols and uses the same implementation of those 222 0 stevel encodings. 223 0 stevel 224 0 stevel 225 0 stevel 5. SUNWssh's Alternative Privilege Separation 226 0 stevel 227 0 stevel The Sun Microsystems ssh team believes that the OpenSSH team has 228 0 stevel reached the point of diminishing returns in attempting to separate 229 0 stevel processing of the user authentication protocols and that the OpenSSH 230 0 stevel approach to privilege separation of the key exchange protocols has 231 0 stevel led to a situation in which the monitor acts as an oracle, willing 232 0 stevel to sign anything provided by the unprivileged processes that talk to 233 0 stevel it. 234 0 stevel 235 0 stevel The Sun ssh team proposes a somewhat different privilege separation 236 0 stevel implementation that shares with the OpenSSH model the goal of 237 0 stevel minimizing and simplifying the protocol spoken by the monitor, but 238 0 stevel little source code. 239 0 stevel 240 0 stevel We eschew any temptation to apply the privilege separation concept 241 0 stevel to the version negotiation, initial key exchange and user 242 0 stevel authentication phases of the ssh protocols (but see section 7). 243 0 stevel 244 0 stevel Instead we focus on separating processing of auditing, record 245 0 stevel keeping and re-keying from processing of the session protocols. We 246 0 stevel also wish to avoid creating any oracles in the monitor. 247 0 stevel 248 0 stevel This approach allows us to have a very simple monitor protocol. Our 249 0 stevel monitor protocol consists of the following operations: 250 0 stevel 251 0 stevel - record a new pseudo-terminal session 252 0 stevel - record the end of a pseudo-terminal session 253 0 stevel - process a re-key protocol messages 254 0 stevel - get keys negotiated during re-keying to the session process to it 255 0 stevel can use them 256 0 stevel 257 0 stevel Logout auditing is done when the session process dies and so does 258 0 stevel not require a monitor protocol message. 259 0 stevel 260 0 stevel By processing all re-key protocol messages in the monitor we prevent 261 0 stevel the creation of oracles in the monitor. This is so because the 262 0 stevel monitor signs only material which it has generated and over which an 263 0 stevel attacker would have little influence (through the attackers offered 264 0 stevel DH public key, for example). 265 0 stevel 266 0 stevel Odds and ends: 267 0 stevel 268 0 stevel - If the monitor receives SIGHUP, SIGTERM or SIGINT it will call 269 0 stevel fatal_cleanup(), and thence will forcibly shutdown(3SOCKET) the 270 0 stevel ssh connection socket, causing its child to exit, and audit a 271 0 stevel logout. 272 0 stevel 273 0 stevel - The monitor does not attempt to update utmpx/wtmpx independently 274 0 stevel of its child -- it depends on the child asking it to. 275 0 stevel 276 0 stevel - The child now is unable to chown() ptys back to root. That's Ok, 277 0 stevel other services on Solaris do the same and everything still works 278 0 stevel because of grantpt(3C). 279 0 stevel 280 7574 Jan - The sshd server process (the one that will become a monitor) 281 7574 Jan forks a child process before the key exchange starts. The reason 282 7574 Jan for it is that if we forked after that we would end up using 283 7574 Jan PKCS#11 sessions initialized in the monitor unless 284 7574 Jan UseOpenSSLEngine was explicitly set to 'no'. Using any existing 285 7574 Jan PKCS#11 sessions or object handles over fork is what the PKCS#11 286 7574 Jan standard explicitly prohibits. To solve that, we would have to 287 7574 Jan rekey before fork and then newly initialize the engine in the 288 7574 Jan child, together with the new crypto contexts initialized with the 289 7574 Jan keys produced by the key re-exchange. And, that wouldn't help in 290 7574 Jan situations where the client does not support rekeying which also 291 7574 Jan includes the whole protocol version 1. The pre-fork solution is 292 7574 Jan simpler and also much faster. So, the key exchange and 293 7574 Jan authentication is fully done in the child server process while 294 7574 Jan the monitor waits aside to read the authentication context that 295 7574 Jan is needed for further operation. The child drops privileges after 296 7574 Jan the authentication finishes. 297 7574 Jan 298 7574 Jan With the ssh client, the situation is slightly more complicated. 299 7574 Jan Given the fact that the user can request to go to the background 300 7574 Jan during the connection using the ~& sequence we must be prepared 301 7574 Jan to rekey before forking, to reinitialize the engine in the child 302 7574 Jan after that, and then set the new crypto contexts with the new 303 7574 Jan keys. If the server we are communicating with does not support 304 7574 Jan rekeying we will not use the engine at all. We expect this 305 7574 Jan situation to be extremely rare and will not offer any workaround 306 7574 Jan for that. This also includes the protocol version 1. However, 307 7574 Jan this version is already considered obsolete and should not be used 308 7574 Jan if possible. 309 0 stevel 310 0 stevel 6. Comparison of the OpenSSH and SUNWssh PrivSep Models 311 0 stevel 312 0 stevel The OpenSSH server involves three processes which we will term 313 0 stevel "pre-session," "session" and "monitor." 314 0 stevel 315 0 stevel The OpenSSH pre-session process implements: 316 0 stevel 317 0 stevel - the ssh version string exchange 318 0 stevel - the ssh message encoding/decoding 319 0 stevel - most of the initial key exchange protocols 320 0 stevel - transport protection 321 0 stevel - part of the user authentication protocols 322 0 stevel 323 0 stevel The OpenSSH session process implements: 324 0 stevel 325 0 stevel - the ssh message encoding/decoding 326 0 stevel - transport protection 327 0 stevel - most of the re-keying protocols 328 0 stevel - the session protocols 329 0 stevel 330 0 stevel The OpenSSH monitor process implements: 331 0 stevel 332 0 stevel - the ssh message encoding/decoding 333 0 stevel - parts of the key exchange and re-key protocols (primarily signing 334 0 stevel of server replies with host private keys) 335 0 stevel - most of the user authentication protocols, specifically: 336 0 stevel 337 0 stevel - evaluation of ~/.ssh/authorized_keys (for pubkey userauth) 338 0 stevel - evaluation of known hosts files (for hostbased userauth) 339 0 stevel - evaluation of .shosts/.rhosts files (for hostbased userauth) 340 0 stevel - verification of signatures w/ public keys (pubkey, hostbased) 341 0 stevel - PAM API calls, conversation function 342 0 stevel - GSS-API calls 343 0 stevel 344 0 stevel Note that any vulnerabilities in the parsing of authorized_keys, 345 0 stevel known hosts and .shosts/rhosts files are as exploitable in the 346 0 stevel monitor as in a server w/o privilege separation. 347 0 stevel 348 0 stevel Similarly for any vulnerabilities in PAM modules and GSS-API 349 0 stevel mechanisms. 350 0 stevel 351 0 stevel The SUNWssh server involves two processes which we will term 352 0 stevel "session" and "monitor." 353 0 stevel 354 0 stevel The SUNWssh monitor process implements: 355 0 stevel 356 0 stevel - the ssh version string exchange 357 0 stevel - the ssh message encoding/decoding 358 0 stevel - transport protection 359 0 stevel - all of the key exchange and re-key protocols 360 0 stevel - all of the user authentication protocols 361 0 stevel 362 0 stevel The SUNWssh session process implements: 363 0 stevel 364 0 stevel - the ssh message encoding/decoding 365 0 stevel - transport protection 366 0 stevel - the session protocols 367 0 stevel 368 0 stevel Obviously all of these processes also implement their side of the 369 0 stevel monitor protocols. 370 0 stevel 371 0 stevel The OpenSSH 3.5p1 monitor protocol, on Solaris, has approximately 20 372 0 stevel monitor request and corresponding response messages. 373 0 stevel 374 7574 Jan The SUNWssh monitor protocol has 5 monitor request and response 375 0 stevel messages; additionally, the monitor processes standard re-key 376 0 stevel messages (but note: the monitor and the session process IPC is 377 0 stevel completely unencrypted), which amounts to about 14 more messages 378 0 stevel altogether. 379 0 stevel 380 0 stevel Much of the OpenSSH monitor protocol is a variation of the 381 0 stevel on-the-wire ssh protocols, with some contents re-packaging. We 382 0 stevel believe this does not afford the monitor much additional, if any 383 0 stevel protection from attacks in the key exchange and user authentication 384 0 stevel protocols. 385 0 stevel 386 0 stevel The re-packaging that is done in the OpenSSH monitor protocol is 387 0 stevel risky business. By separating the act of signing some blob of data 388 0 stevel from computing that blob of data one can create an oracle; this is 389 0 stevel exactly what happened in the OpenSSH case. 390 0 stevel 391 0 stevel As you can see in the next section, the SUNWssh privilege separation 392 0 stevel could evolve somewhat in the OpenSSH direction by saving the monitor 393 0 stevel all transport protection work, but we cannot save the monitor much, 394 0 stevel if any work relating to authentication or key exchange. 395 0 stevel 396 0 stevel 397 0 stevel 7. Future Directions 398 0 stevel 399 0 stevel The SUNWssh server privilege separation implementation could stand 400 0 stevel several improvements. 401 0 stevel 402 0 stevel The first improvement would be to have a single system-wide monitor. 403 0 stevel This would reduce resource consumption. The work needed to 404 0 stevel implement such an enhancement is very similar to the work needed to 405 0 stevel produce an SSH API and library, and it is not trivial. If this is 406 0 stevel not done then at least dropping PRIV_PROC_SETID and instead setting 407 0 stevel the saved-set-user-id in the monitor to that of the logged in user 408 0 stevel would be nice. 409 0 stevel 410 0 stevel The second enhancement would be to add a "none" host key algorithm 411 0 stevel to SSHv2 and a corresponding option in SUNWssh to disallow re-keying 412 0 stevel with any other host key algorithm. This would allow customers to 413 0 stevel configure their server and monitor so that no re-key protocol 414 0 stevel messages need be processed by the monitor. 415 0 stevel 416 0 stevel A third enhancement would be to enhance the GSS-API mechanisms to 417 0 stevel require fewer privileges. In practice this means overhauling the 418 0 stevel Kerberos V mechanism's replay cache. This would allow the monitor 419 0 stevel to run with fewer privileges. 420 0 stevel 421 0 stevel Further, even without improving the Kerberos V mechanism's replay 422 0 stevel cache it should be possible to drop at least PRIV_PROC_FORK/EXEC/ 423 0 stevel SESSION. 424 0 stevel 425 0 stevel A fourth enhancement would to have the unprivileged process handle 426 0 stevel all transport protection and proxy to the monitor all key exchange 427 0 stevel and user authentication protocol messages. This is a variation on 428 0 stevel the OpenSSH model, but without the re-packaging of ssh message 429 0 stevel contents seen there. After authentication succeeds the monitor 430 0 stevel could either change the unprivileged process' credentials (as can be 431 0 stevel done with ppriv(1) or the unprivileged process would, as in OpenSSH, 432 0 stevel pass the session keys/IVs/keystate to the monitor which would then 433 0 stevel pass them to a new process, the session process, that would then run 434 0 stevel as the logged in user. 435 0 stevel 436 0 stevel 437 0 stevel 8. Guide to the AltPrivSep Source Code 438 0 stevel 439 0 stevel 440 0 stevel First, a brief introduction to the SUNWssh/OpenSSH source code. 441 0 stevel 442 0 stevel The source code is organized as follows: 443 0 stevel 444 0 stevel $SRC/cmd/ssh/etc/ 445 0 stevel | 446 0 stevel +-> config files 447 0 stevel 448 0 stevel $SRC/cmd/ssh/include/ 449 0 stevel | 450 0 stevel +-> header files (note: none are installed/shipped) 451 0 stevel 452 0 stevel $SRC/cmd/ssh/libopenbsd-compat/common/ 453 0 stevel | 454 0 stevel +-> misc. portability source code 455 0 stevel 456 0 stevel $SRC/cmd/ssh/libssh/common/ 457 0 stevel | 458 0 stevel +-> implementation of encoding, transport protection, 459 0 stevel various wrappers around cryptography, the key exchange 460 0 stevel and host authentication protocols, the session 461 0 stevel protocols, and misc. other code 462 0 stevel 463 0 stevel cipher.c 464 0 stevel mac.c 465 0 stevel compress.c 466 0 stevel packet.c 467 0 stevel | 468 0 stevel +-> transport protocol 469 0 stevel 470 0 stevel buffer.c 471 0 stevel bufaux.c 472 0 stevel | 473 0 stevel +-> encoding 474 0 stevel 475 0 stevel channels.c 476 0 stevel nchan.c 477 0 stevel | 478 0 stevel +-> session protocol 479 0 stevel 480 0 stevel kex.c 481 0 stevel kexdh.c 482 0 stevel kexgex.c 483 0 stevel | 484 0 stevel +-> key exchange/re-key code common to ssh and sshd 485 0 stevel 486 0 stevel kexdhs.c 487 0 stevel kexgexs.c 488 0 stevel kexgsss.c 489 0 stevel | 490 0 stevel +-> key exchange/re-key code (server only) 491 0 stevel 492 0 stevel kexdhc.c 493 0 stevel kexgexc.c 494 0 stevel kexgssc.c 495 0 stevel | 496 0 stevel +-> key exchange/re-key code (client only) 497 0 stevel 498 0 stevel dh.c 499 0 stevel rsa.c 500 0 stevel mpaux.c 501 0 stevel ssh-rsa.c 502 0 stevel ssh-dss.c 503 0 stevel ssh-gss.c 504 0 stevel | 505 0 stevel +-> crypto wrappers/utilities 506 0 stevel 507 0 stevel log.c 508 0 stevel | 509 0 stevel +-> logging, including debug logging, on stderr or 510 0 stevel syslog 511 0 stevel 512 0 stevel 513 0 stevel $SRC/cmd/ssh/ssh/ 514 0 stevel | 515 0 stevel +-> ssh(1) 516 0 stevel 517 0 stevel $SRC/cmd/ssh/sshd/ 518 0 stevel | 519 0 stevel +-> sshd(1M), including auditing, implementation of user 520 0 stevel authentication and the OpenSSH and SUNWssh monitors 521 0 stevel 522 0 stevel sshd.c 523 0 stevel | 524 0 stevel +-> main() 525 0 stevel 526 0 stevel auth*.c 527 0 stevel | 528 0 stevel +-> user authentication 529 0 stevel 530 0 stevel serverloop.c 531 0 stevel session.c 532 0 stevel | 533 0 stevel +-> session protocols 534 0 stevel 535 0 stevel bsmaudit.[ch] 536 0 stevel sshlogin.c 537 0 stevel loginrec.c 538 0 stevel | 539 0 stevel +-> auditing and record-keeping 540 0 stevel 541 0 stevel $SRC/cmd/ssh/<misc commands>/ 542 0 stevel | 543 0 stevel +-> scp, sftp, sftp-server, ssh-agent, ssh-add, ... 544 0 stevel 545 0 stevel 546 0 stevel The SUNWssh altprivsep adds two new source files: 547 0 stevel 548 0 stevel $SRC/cmd/ssh/include/altprivsep.h 549 0 stevel $SRC/cmd/ssh/sshd/altprivsep.c 550 0 stevel | 551 0 stevel +-> monitor start routine, altprivsep_packet_*() routines 552 0 stevel for communication with the monitor, routines to help 553 0 stevel with key exchanges, service procedures for the monitor, 554 0 stevel etc... 555 0 stevel 556 0 stevel and modifies the following: 557 0 stevel 558 0 stevel $SRC/cmd/ssh/include/config.h 559 0 stevel | 560 0 stevel +> adds cpp define "ALTPRIVSEP" 561 0 stevel 562 0 stevel $SRC/cmd/ssh/include/ssh2.h 563 0 stevel | 564 0 stevel +-> adds private message type "SSH2_PRIV_MSG_ALTPRIVSEP" (254) 565 0 stevel 566 0 stevel $SRC/cmd/ssh/include/packet.h 567 0 stevel | 568 0 stevel +-> adds prototypes for several simple utility functions, 569 0 stevel some of which are specifically meant to avoid having to 570 0 stevel link altprivsep.c into ssh(1) 571 0 stevel 572 0 stevel $SRC/cmd/ssh/libssh/common/kex.c 573 0 stevel $SRC/cmd/ssh/libssh/common/packet.c 574 0 stevel | 575 0 stevel +-> implements the hooks needed to proxy re-key messages 576 0 stevel to/from the monitor 577 0 stevel 578 0 stevel $SRC/cmd/ssh/sshd/Makefile 579 0 stevel | 580 0 stevel +-> adds altprivsep.o to list of objects linked into sshd(1M) 581 0 stevel 582 0 stevel $SRC/cmd/ssh/sshd/serverloop.c 583 0 stevel | 584 0 stevel +-> adds an event loop for the monitor 585 0 stevel modifies the usual event loops for SSHv2 586 0 stevel 587 0 stevel $SRC/cmd/ssh/sshd/session.c 588 0 stevel | 589 0 stevel +-> modifies do_login() and session_pty_cleanup2() to call 590 0 stevel altprivsep_record_login/logout() instead of 591 0 stevel record_login/logout(). 592 0 stevel 593 0 stevel modifies do_exec_pty() so that the server waits for the 594 0 stevel call to altprivsep_record_login() in child process to 595 0 stevel complete before returning so that the server and the 596 0 stevel child processes do not compete for monitor IPC I/O. 597 0 stevel 598 0 stevel $SRC/cmd/ssh/include/log.h 599 0 stevel $SRC/cmd/ssh/libssh/common/log.c 600 0 stevel | 601 0 stevel +-> adds an internal interface, set_log_txt_prefix() so that 602 0 stevel the monitor's debug and log messages get prefixed with a 603 0 stevel string ("monitor ") that indicates they are from the 604 0 stevel monitor 605 0 stevel 606 0 stevel $SRC/cmd/ssh/sshd/sshd.c 607 0 stevel | 608 0 stevel +-> modifies the body of code that follows the user 609 0 stevel authentication phase of the ssh protocols so as to start 610 0 stevel the monitor and move the relevant code into the monitor 611 0 stevel or session processes as appropriate while dropping 612 0 stevel privileges and access to privileged resources in the 613 0 stevel session process 614 0 stevel 615 0 stevel The monitor uses the packet.h interfaces to communicate with the 616 0 stevel session process as though it were its ssh client peer, but always 617 0 stevel uses the "none" cipher, mac and compression algorithms and installs 618 0 stevel even handlers only for the relevant key exchange messages and the 619 0 stevel private monitor message used for the other monitor services. 620 0 stevel 621 0 stevel The monitor serves the following services: 622 0 stevel 623 0 stevel - APS_MSG_NEWKEYS_REQ -> used to obtain keys/IVs after re-keys 624 0 stevel - APS_MSG_RECORD_LOGIN -> used to update utmpx/wtmpx 625 0 stevel - APS_MSG_RECORD_LOGOUT -> used to update utmpx/wtmpx 626 0 stevel 627 0 stevel The session and monitor processes communicate over a pipe. 628 0 stevel 629 0 stevel All monitor IPC I/O from the session process is blocking (though the 630 0 stevel pipe is set to non-blocking I/O). The monitor protocol is entirely 631 0 stevel synchronous and relies on the re-key protocols being entirely 632 0 stevel synchronous also (which they are, unlike the session protocols). 633 0 stevel 634 0 stevel The kex.c and packet.c files are minimally modified, primarily to 635 0 stevel prevent the monitor from handling SSH_MSG_NEWKEYS messages as a 636 0 stevel normal ssh server should, instead letting the session process 637 0 stevel process SSH_MSG_NEWKEYS messages by requesting the new keys 638 0 stevel negotiated with client from the monitor. 639 0 stevel 640 0 stevel Note that for SSHv1 no on-the-wire messages are processed by the 641 0 stevel monitor after authentication. In fact, the monitor thinks it's 642 5562 jp161948 running SSHv2, even if the on-the-wire protocol is v1. 643 0 stevel 644 0 stevel 645 0 stevel A. References 646 0 stevel 647 0 stevel The IETF SECSH Working Group: 648 0 stevel 649 0 stevel http://www.ietf.org/html.charters/secsh-charter.html 650 0 stevel 651 0 stevel The SSHv2 architecture, assigned numbers: 652 0 stevel 653 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-16.txt 654 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-06.txt 655 0 stevel 656 0 stevel New cipher modes for SSHv2: 657 0 stevel 658 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-02.txt 659 0 stevel 660 0 stevel The SSHv2 "transport," including initial key exchange and re-key 661 0 stevel protocols, but excluding negotiable DH group size and GSS-API-based 662 0 stevel key exchange: 663 0 stevel 664 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-18.txt 665 0 stevel 666 0 stevel Additional key exchange protocols for SSHv2: 667 0 stevel 668 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-08.txt 669 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-04.txt 670 0 stevel 671 0 stevel Base user authentication spec for SSHv2 (includes none, password, 672 0 stevel pubkey and hostbased user authentication): 673 0 stevel 674 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-21.txt 675 0 stevel 676 0 stevel SSHv2 user authentication using PAM-style prompting: 677 0 stevel 678 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-06.txt 679 0 stevel 680 0 stevel SSHv2 user authentication using the GSS-API: 681 0 stevel 682 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-08.txt 683 0 stevel 684 0 stevel SSHv2 "session" protocol (i.e., the protocol used for pty sessions, 685 0 stevel port forwarding, agent forwarding, X display forwarding, etc...): 686 0 stevel 687 0 stevel http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-19.txt 688
Indexes created Tue Nov 24 11:10:09 UTC 2009
Terms of Use |
Privacy |
Trademarks |
Copyright Policy |
Site Guidelines |
Help
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Use.
Copyright © 1995-2008 Sun Microsystems, Inc.