Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems BSD

OpenSSH Gets Even More Suspicious 312

Posted by timothy from the mother-may-i dept.
If you remotely administer any computers, or need to check your email over an untrusted network, odds are you're already familiar with the wonders of OpenSSH. Markus Friedl yesterday posted a release announcement for the newest version, OpenSSH 3.3. Privilege separation in OpenSSH is now enabled by default, another sign of the entire OpenBSD project's appropriate paranoia.
This discussion has been archived. No new comments can be posted.

OpenSSH Gets Even More Suspicious More

OpenSSH Gets Even More Suspicious

Comments Filter:
  • to bad that its not default on EVERY **nix

  • Slashdot to English (Score:4, Funny)

    by ReluctantBadger ( 550830 ) on Saturday June 22, 2002 @03:02PM (#3749719) Homepage Journal

    1st Official Slashdot to English Translator-matic
    • "There's a sourceforge project creating just what you're looking for..."
      "Me and a bunch of people got drunk, thought we could code, submitted the idea and produced a fancy web page. It's now two years later and the project has no files to download and is STILL on Stage 1, Planning."

    • "That's the beauty of UNIX - Lots of little tools which can be used together. Far more flexible!"
      "I've been reading UNIX in a Nutshell for SVR4 and fuck knows what any of this flags stuff is about"

    • "Linux is far more secure than Windows. My box has never been hacked."
      "I can install Red Hat from a bootable CD. The machine is not connected to a network and all I do all day is type ps, pwd and ls. I'm so l33t."

    • "You might want to try going to college and learning about this stuff!"
      "My folks are rich enough to send me off for further education. I am now in an uber-elite crowd of know-it-alls and I am here to belittle you. Fear me."

    • "Microsoft products are soooo insecure!"
      "I've spent the last two years being subjected to biased slashdot propaganda. I couldn't hack into a properly configured windows system if my life depended on it."

    • "We should file an antitrust lawsuit against Sony"
      "I've spent far too much time absorbing bullshit ideals from anarchists. The truth of the matter is, I just don't want to pay for anything whatsoever. Britney CDs should be free because I think that somehow the constitution protects my illegal copying and distribution under some freedom of speech law or fair use act. Even though I don't have to go out and buy luxury items, I'm gonna whinge and bitch anyway"

    • "Have you considered using Linux?"
      "I've only been using it for a week, and now my hardcore wannabe techno friends think I'm a guru. I now recommend it to everybody based upon what I've read at slashdot."

    • "Don't you find that parsing this bitset through the compliation alogirithm that is piped out through GCC on a command line echo really works well for logarithmically sound sine wave matcher?"
      "Somebody please shoot me several times in the head. I am fucking clueless."

    • "If they join all the state drivers licence databases together, they'll be able to track me! How do I change my identity?"
      "I'm too fucking dense to realise that this has been going on for over 15 years already, and I've just finished reading 1984. Go figure."


  • One of the primary tenets of OpenBSD and NetBSD is security, correct? This is just another little bit of bytecode that improves security even more...
    • I think you mean OpenBSD.
    • One of the primary tenets of OpenBSD and NetBSD is security, correct? This is just another little bit of bytecode that improves security even more...

      Absolutely. Now if only we can get Microsoft to use unprivilaged children for IIS, we might be getting somewhere.

      Not that I am advocating child labor (well, children of Daemons maybe ;))

  • More suspicious of OpenSSH? (Score:5, Insightful)

    by jamus ( 1439 ) on Saturday June 22, 2002 @03:06PM (#3749734) Journal
    The way I read the headline, "OpenSSH Gets Even More Suspicious", it sounded like we're supposed to be more suspicious of OpenSSH.

    What has the world come to, where we can't even trust OpenSSH?

    Oh, OpenSSH is more suspicious of its environment! That makes more sense! :P
    • I read that too and my mind quickly said to me "Oh great, time to turn off SSH and only allow shell access to people who physically sit down at the computer.

      Then I realized that it's "suspicious" as in "the suspicious wife accused her husband of sneaking another computer into the house" and not "the actions of the husband were suspicious, leading his wife to accuse him of sneaking another computer into the house."

      Should have said "Open SSH has just become even more paranoid."

      THIS is why computers don't speak English. =]

      -Sara
      • Complete agreement. When I read the headline, there was a sudden pang of fear. If we had to close down SSH, there wouldn't be any more working-from-home Fridays. :)
        • If we had to close down SSH, there wouldn't be any more working-from-home Fridays. :)

          Sure there would.
          Telnet isn't that bad.
          You just have to have your login script change your password as soon as you log in remotely.
          If you can't remember to *always* log in to the console before you go to work, then the reinstall will prove a useful lesson.

        • Maybe that was the idea.

          Isn't a headline supposed to make you want to read the article?

    • Timothy (Score:4, Funny)

      by jhines ( 82154 ) <john@jhines.org> on Saturday June 22, 2002 @04:29PM (#3749990) Homepage
      It is Timothy that we don't trust.
    • Well yeah. Statistically, OpenSSH has had 2x more serious security related bugs since it forked from commercial SSH. Apparently in their zest to fix what isn't necessarily broken, OpenSSH has ended up with more holes than it started with. This might be a legitimate explanation as to why they are going to separate privileges: when a month-old freenix weenie is given commit access to openssh and writes a patch but forgets to make sure he is using dynamic buffers, everyone who likes being on the bleeding edge doesn't get rooted after they upgrade.

      At one institution I am aware of, the new administration policy has been to convert from openssh over to commercial ssh because of paranoia. Furthermore, when core server software is written such that you must upgrade every few months due to vulnerabilities in the latest-and-greatest, it hinders deployment of autonomous and/or embedded systems that rely on software such as SSH. Basically, if I wanted to build either an autonomous server or embedded system today, and decided to use OpenSSH 3.1.2 - which is supposedly stable, and a remotely exploitable vulnerability is found next month, the box is pretty much screwed, especially if no one is there to administer that machine and to appropriately upgrade it.

  • Impressive (Score:4, Insightful)

    by dybdahl ( 80720 ) <infoNO@SPAMdybdahl.dk> on Saturday June 22, 2002 @03:07PM (#3749741) Homepage Journal
    Open Source software continues to impress me after so many years. This again proves, how much better software can be, if you remove management, lawyers, sales department etc. and make good programmers work together without short-term profit in mind.

    • Re:Impressive (Score:1, Insightful)

      by RebelTycoon ( 584591 )
      "how much better software can be, if you remove management, lawyers, sales department etc. and make good programmers work together without short-term profit in mind."


      What you smoking.. Wanna share?

      Management and a Sales Department are necessary, have you ever tried to get a geek to explain what they built in English?

      Programmers do not make good sales people usually, it takes a lot of practice to talk to people in the appropriate language and level of technicallity.

      And programmers left alone would be responsible for even more feature-creep then sales or management. We always like kwel stuff, a what if we do this.. Unfortunately we must be restrained.

      As a side note, at least we usually don't change the scope of the project or promise the undeliverable..

      Lawyers... This I'll agree with you... Same goes for Politicians, etc.

      • And programmers left alone would be responsible for even more feature-creep then sales or management. We always like kwel stuff, a what if we do this.. Unfortunately we must be restrained.

        Mozilla's XUL user interface, anyone?

        No offense meant, but how long would it had take to make 3 gecko-based browsers (Win,Lin,Mac) using native widgets instead of spending so much time with the kewl "write-once-bugs-everywhere" interface.
  • Open Secure Shell? Is that like Passive Agression?
  • You've heard of the recent apache bug [slashdot.org]. Apparently, the OpenBSD team is announcing it as a "possible remote crash" [openbsd.org].

    Since a remote exploit [securityfocus.com] already exists, shouldn't they detail the severity on their front page?

    Nothing against the OpenBSD team... I believe they do excellent work, but heck, people, PLEASE patch up those systems! It's only a matter of days before someone is going to drop a new worm! This is horribly serious!

    • Re:Even OpenBSD developers can be vain... (Score:4, Informative)

      by The_Final_Word ( 580419 ) on Saturday June 22, 2002 @03:21PM (#3749789)
      upgrade to Apache 1.3.26 or 2.0.39, it's an Apache problem and it is on their home page.

      http://httpd.apache.org/

      The OpenBSD folks gave a patch for the OS before the new Apache binaries were released as a work around.

    • You mean they didn't accept the patch you wrote for them!? Ludicrous. Maybe they're too busy being whipped along by people who don't give anything back to the OS community to evaluate your code. ;) I mean... You obviously feel strongly about it so you HAVE to have written a patch, no?

      If they KNOW about it, and I'm sure they do, then they'll patch it. They're not Microsoft, afterall. In the meantime, if you're not a developer, lay off the whip. Like you said- the bug is recent, if they let a few months fly by without doing anything then you can start complaining.

      -Sara

    • Apparently, the OpenBSD team is announcing it as a "possible remote crash"... It's only a matter of days before someone is going to drop a new worm!

      Wow. If you can figure out how to exploit a remote crash to spread a worm, you're a lot smarter than I am, dude.

    • The problem is that it doesn't appear that anyone has been able to make the alleged remote root exploit work. I haven't read misc@openbsd.org this weekend, but the consensus of the list as of yesterday was that it was not a legitimate root exploit.

      And generally, since apache is not running by default, the OpenBSD team would tend to be of the mindset that if you are going to turn it on, you better stay up to speed on it.

      not speaking for the team of course,
      ostiguy
    • 1. OpenBSD does not start httpd by default.
      2. The exploit opens up a terminal that appears to be a root term, but is actually a fake. It only has nobody privs.

      If you don't read the lists, then look at the archives. The exploit is humorous, but against Apache. The OpenBSD crew don't write Apache, they just fix it when it breaks.

      The most stable OS to be running it on, would be OpenBSD.

  • SSH is magnificent! (Score:4, Interesting)

    by dmarien ( 523922 ) <dmarien&dmarien,com> on Saturday June 22, 2002 @03:20PM (#3749783) Homepage
    When I first started using linux, I was absolutely blown away by telnet, and the capabilities for remote administration.

    Then came SSH... Not only is the grade of encryption absolute phenomenal, but the extras above and beyond remote shell's are astounding!

    X Forwarding, SCP, FTPs, etc... they all rock! I can't remember the last time I coped a file over any protocol other than SSH's scp command. WinSCP has replaced puTTY as my favorite WIN32 application, and combined with puTTY and secure shells it's now wonder how I've managed to keep my home router/server up for 180 days w/o even having a monitor plugged into it!

    Thanks OpenSSH team!

    • Re:SSH is magnificent! (Score:5, Informative)

      by p3d0 ( 42270 ) on Saturday June 22, 2002 @03:42PM (#3749856)
      Just remember to use the "blowfish" cypher for large files. It's much faster than the default 3DES.

      I use: alias scp="scp -c blowfish-cbc".
      • Does it exist or is anyone working on AES for scp?

        • Re:SSH is magnificent! (Score:3, Informative)

          by Sircus ( 16869 )
          SCP runs over the standard SSH protocol (either SSH1 or SSH2). All SSH security features therefore apply to SCP.

          128-bit AES/Rijndael is one of the "recommended" ciphers for SSH2, but is not supported by SSH1. 192 and 256 bit AES/Rijndael are "optional" for SSH2.

          • Re:SSH is magnificent! (Score:5, Interesting)

            by demaria ( 122790 ) on Saturday June 22, 2002 @05:53PM (#3750359) Homepage
            Thanks for the info. Something else cool, SSH with Tokens. I saw a demo at N+I on the commercial SSH 3.0 by SSH Communications. You need to have a token (such as an e-Aladdin USB eToken) plugged in during the entire session. If the token is removed, the shell instantly drops.
            • Hey, that is neato. Can you supply it with your own random stream for the keys? I was think of something like this recently.

              I would like a real, strong key that I could plug in and out as I need to use my machines and sessions.

              Can you supplement it's usage with an extra password to avoid the usage of that key if it gets stolen?

              • I don't recall completely all the details about how it works, and it was about a month ago. However I thought it was pretty spiffy at the show. I'm not sure about the random stream for the keys and would rather not guess an answer, especially with security :). In the demo I saw there was a password that needed to be entered for it to work, which would affirmatively answer your second question. Check their website or call. Keep in mind this setup requires each machine to have an accessible USB port (assuming you use a USB token of course), and the commercial SSH (not OpenSSH).
      • An alias is not the best idea.

        Best thing to do, edit your ~/.ssh/config and stick your options in there (or machine-wide if you edit /etc/ssh/ssh_config).

        So, enter something like:

        host *
        Compression no
        Ciphers Blowfish-cbc,3des-cbc
        Protocol 2,1

        Additionally, use DSA/RSA auth, (NOT PASSWORD), and use ssh-agent so that you only need to enter your key's pass-phrase once in a while.

        Anyone that uses SSH (and doesn't yet know about scp, port forwarding, ssh-agent, key-based auth & configuration like above) should buy the O'reilly SSH book.
    • As someone who used to go around cracking *NIX systems, and sniffing out login/passwords with ridiculous ease back in the early to mid 90s, I can say yes SSH is a very good thing. It was good to see sysadmins shut down their telnet daemons for good and require that people download and use a SSH client to connect to systems.

    • Re:SSH is magnificent! (Score:2, Informative)

      by rweir ( 96112 )
      X Forwarding, SCP, FTPs
      You think that's impressive? Have a look at the -D flag to OpenSSH >3.0: That's right, ssh can now run an encrypted forwarding SOCKS4 server!
      Goddamn!

    • Monitor plugged into it? You have a video card in the machine? /me boggles at the thought.

  • Other than the tty and authentication seperation, this doesn't sound a whole lot different than running sshd out of inetd. Or have I been smoking crack again without my knowledge?

    • Re:um, inetd? (Score:2, Interesting)

      by PacoTaco ( 577292 )
      It's totally different. If you run sshd from inetd, you are still processing network data as root. If someone finds a buffer overflow (or whatever) they can execute arbitrary code as root on your system. This strategy uses an unprivileged user to do most of the network data processing, with a privileged parent process for verification and authentication. At worst, a remote attacker could only get access as the unprivileged user.

  • Uh...? (Score:4, Interesting)

    by JanusFury ( 452699 ) <kevin...gadd@@@gmail...com> on Saturday June 22, 2002 @03:46PM (#3749866) Homepage Journal
    For those of us without much experience in the encryption and networking fields, anyone mind explaining exactly what this does? I read the page but I'm not sure I understand exactly what's going on.
    • To put it simply:

      Encrypted Telnet.

    • Re:Uh...? (Score:2, Informative)

      by PacoTaco ( 577292 )
      Handling arbitrary data from the network as root is a bad thing. Basically, an attacker's exploits run at the same privilege level as the daemon they break in through. The new OpenSSH strategy uses a non-root user to do most of the work. That way, the attacker doesn't have immediate root access to your system if sshd is compromised.

    • Re:Uh...? (Score:3, Informative)

      by LinuxGeek8 ( 184023 )
      I'm not into it that much too. But simply said it starts different processes.
      The parent process starts with root priviliges, and the child processes handle the actual connections, and do not run with root priviliges.
      For things like authentication the child communicates with the parent. Hmm, would that mean a new connection needs to authenticate itself twice then? (in 1 login) I assume so.
      If the child gets corrupted, or someone tries to break in, he will not have the root priviliges of the parent process.

      In previous ssh versions it was always running with root priviliges, even if you were logged in as user. So every exploit in openssh is immediately a remote root exploit.

      This is sort of the same model that Apache has, one root parent, the rest runs as user www or whatever.
      The same as postfix, the secure alternative for sendmail, which also runs only as root I believe).

    • What it does - Program, not Protocol Security (Score:5, Informative)

      by billstewart ( 78916 ) on Saturday June 22, 2002 @04:40PM (#3750043) Journal
      This isn't a change to the communications protocols or any of the encryption - it's a change to the Unix implementation of the server to make it much less likely that any bugs can let someone break in. (Initially this works for OpenBSD, should be easy to port to other BSD implementations, probably to Linux and Solaris, maybe to WinNT but maybe not.) The basic way that a communications server like this works is
      • A process sits around listening to the well-known TCP port for connection requests. The process needs to be privileged for two reasons
      • The port is a system resource so only the system should be able to control it
      • When a user logs in (on Unix), their connection needs to operate with the permissions of that user, so the server needs to be root so it can start a session as any user who logs in (as opposed to a Web Server, which usually only needs access to publicly readable files.

      When a request comes in, it hands it to a subroutine that handles requests for the server to do different functions, including authentication.

      For some services, such as SSH and FTP, the server may set up multiple connections for things like transferring files, etc.You can write a server like this as one big single-threaded process, or as one big process with multiple threads if your operating system and programming environment support it, but it's more common, especially on Unix, for the main process to spin off several child processes to do the work and go back to listening for new incoming requests. In this case, it spins of one process to handle the control channel communications and that process spins off other processes to handle specific tasks like file transfers, after checking that the connection and the request are authenticated. In a simple-minded implementation, the control channel process runs as root, and any task channel processes start off as root, and maybe change their privileges to an individual user's privileges if they need to (for instance if you're using SSH to log in to a remote system.)

      The problem with this is that if there are any bugs that let a remote connection send messages with unexpected data in ways that break or take over the server process, the server is running as root so it can do anything it wants, however evil or dangerous (or if it's a minor bug that doesn't lead to a complete takeover, it may still be able to burn critical resources and stall the system or do some other denial of service attack.) Two popular kinds of attacks are sending a message that overflows a field (the result of bad protection in the C language combined with careless programming), or sending a message that asks the process to do something that the programmer didn't expect and protect against, such as setting permissions on a system file or making a user's program privileged, so that it can be exploited later, either by another communication from the attacker or by routine activities by the system or the user.

      What the new OpenSSH implementation does is takes the bottom two server processes (the control channel server and the task servers) and splits each of them into two parts that communicate with each other. One part of each processes is a master, that keeps running privileged if it needs to, and the other is a slave process that runs as a non-privileged user (either the user who's requesting the service, for tasks like logins, or as the "nobody" user) and does most of the actual work, passing messages back and forth to the master process to communicate about status and request anything that still requires privileges. This gives you a bunch of security advantages:

      • Each part of the system is smaller, with fewer functions to perform and well-defined interfaces to other parts, so you can do a better job of checking for bugs and each part can validate incoming messages before doing anything.
      • The parts of the system that need to be privileged aren't communicating directly with the remote user, only with the slave processes, so they have a much smaller set of messages to validate.
      • If there's some bug in the system that lets a remote attacker take over one of the control or task processes by sending an craftily designed message, the bug is in the non-privileged slave process, which doesn't run as root, can't do as much damage, and has a limited set of messages that the master process will accept from it.

      The rest of it is basically detail about which functions they separated into which programs, how they made sure that each piece has enough capabilities to do the job without giving it too much power that could be exploited by an attacker, and some stuff about how they validated the pieces. It's adding more complexity to the total system, but each piece is more limited in function, and the security-critical pieces are much easier to validate against bugs and malicious input.

    • I know you've got responses, but I think I've got a much more simple explanation...

      This is essentially like having an application (that need Root access) NOT SUID Root, and rather, having a simple application that it calls when it needs to do some privlidged action.

      So, think of Apache running as a non-privlidged user, and NetCat being SUID Root, and simply calling NetCat when it needs to communicate on a privlidged port, etc.

  • Packet sniffing (Score:2, Interesting)

    by PatJensen ( 170806 )
    Everyone says SSH is great, because your passwords and session information cannot be sniffed and I know that - but how important is it now? You cannot sniff packets on a switched network without SPAN access or port mirroring access on the switch itself. And over multiple switches, it is not trivial to gain access to do that since multiple access ports do not receive unicast frames. Unless you were the switch administrator of all the core and access switches I don't see this happening easily.

    Is there a tool that allows you to force the switch to forward ethernet frames so they can be sniffed without switch administrator access? Please offer some information on how this is done as I'd like to have a better understanding on how this works. What platforms does the tool run on, and on what switch platforms would it work against?

    -Pat (a CCNP and MCSE)

    • Re:Packet sniffing (Score:3, Insightful)

      by GigsVT ( 208848 )
      Who says the attack is local? Your packets cross from 5 to 20 hops before getting to their destination. Routers can be compromised, theough security weaknesses or through deliberate government interference. OpenSSH also allows for host authentication, so you know you are really talking to who you think you are. A secure transport is about more than some guy on your LAN sniffing your password.
    • What if there is one misconfigured router somewhere.. or some chucklehead in sprint wants to collect CC numbers, and they are an admin.

      Not a nice feeling, now is it. It is a bit of paranoia.. but an once of prevention is worth a pound of cure..

    • Ettercap (was Re:Packet sniffing) (Score:5, Informative)

      by Nonesuch ( 90847 ) on Saturday June 22, 2002 @04:12PM (#3749938) Homepage Journal
      Packet sniffing traffic that crosses your ISP and then the public Internet is definitely a serious and real risk.
      PatJensen asks:

      Is there a tool that allows you to force the switch to forward ethernet frames so they can be sniffed without switch administrator access?
      There are tricks to force the switch to 'flood' ethernet frames (overflow the CAM table, etc). Two common attacks against switched segments are MAC spoofing (easily detected and protected against on Cisco) and ARP spoofing (more difficult to protect against).

      There is also a tool to permit packet sniffing, see ettercap [sourceforge.net] on Sourceforge.

      Ettercap is a multipurpose sniffer/interceptor/logger for switched LAN. It supports active and passive dissection of many protocols (even ciphered ones) and includes many feature for network and host analysis.

      Ettercap is actively being used by the "black hat" community, and has been found on compromised systems on switched LAN segments "in the wild".

      • Thanks for the informative response. Is there a place where I can read whitepapers on the viability of CAM overflows and MAC and ARP spoofing? Does Cisco have anything available that relates to this security? I'm aware of port security (only allowing certain MAC address to join a port) and VMPS (a centralized MAC database for VLANs, network wide).

        Would either of these be helpful in prevent these types of attacks?

        Thanks again.

        -Pat

    • Re:Packet sniffing (Score:3, Interesting)

      by mlyle ( 148697 )
      There are plenty of attacks that if you reside on the same virtual lan as one of the victims that allow you to intercept traffic.

      One is sending traffic from the victim's mac address, so that the switch "learns" that MAC is out your port. Port security features on switches can help fix this but are oft-unused.

      Another is ARP spoofing and using that to man-in-the-middle the session. You tell the person logging in that your MAC address is the victim host, and it cheerfully sends all packets to you. This is difficult to detect and prevent.

      In conclusion: switches do not provide security against packet sniffing attacks.

      • Re:Packet sniffing (Score:2, Interesting)

        by mrmag00 ( 200868 )
        The correct conclusion would be "Any cheap switch does not provide security against packet sniffing attacks."

        These things are nothing new, and cisco catalyst switches can be configured to prevent all of these. Of course, they come at a cost - about $1000 for bottom of the line.

    • Re:Packet sniffing (Score:2, Interesting)

      by nr ( 27070 )
      You can sniff switched networks as the ARP querys are sent out to the broadcast address and received by all hosts on the segment, and then you send a fake ARP replie to that ARP query fooling the victim into beliving you are the real host. Poisoning the victims APR cache with your MAC address instead of the real destionation hosts MAC address.

      There exists a sniffer tool called EtterTap that can do this automaticly for you.
    • You can packet storm the switch with tons and tons of mac addresses. eventually the switch won't know where to forward packets because its database will be overflowed. The switch will then drop down to a sort of "hub mode".

      For some reason this attack is common in college dormatories. ;-)

  • There is a better way to fix one of these problems (Score:4, Interesting)

    by thogard ( 43403 ) on Saturday June 22, 2002 @10:43PM (#3751180) Homepage
    You must be root to bind to any port <1024 as a form of "security" however this stupid rule has been the way in for most internet based security problems in the Unix world. Some systems (like Soalris) allow you to turn it off and that lets any process bind to any port but that has issues as well.

    The correct solution is you let a process bind to any port >1024 and any port where the port number is in its group list. This means you put apache process owner in group 80 and 443 and then it can bind it its needed ports no matter who it runs as. Wiht the linux 2.0 kernal this required changing some of one line.

    As far as the other problem of becoming someone else, there are no clean solutions to that but I think it would make sense to allow any process id 10 to become someone else. You also need to allow for some id's to give away files. The problem with this is that it intoduces magic numbers into the system which is bad.

    Based in this, you could set up the ssh user as uid 1 in group 22 and it could bind to port 22 and then become any other user (or maybe any userid > 100). Bind would be running as user 53 with group 53 and have no special privs. The Apache user id would be in group 80 & 433 and its version of suexec would be uid 2 so it could change ownership to any user > 100 to run their cgis.

    • Well, it's something like Network ACLs..

      And it's done, for example in MicroBSD - http://www.microbsd.net

    • The first solution would have made sense, except for the fact group ids are not that changable on production systems. There probably already is a group number 80. But it's a nice start, someday you'll invent ACLs. However your second suggestion is the silliest thing I've ever heard.

      The problem is that ssh can change to any user it wants. That's the PROBLEM, that's the reason that bit was seperated out and away from the network traffic bit. It's not a solution.

      Making it where the process id X (Where X is supposed to be sshd), can change to anyone else, is pretty much a negative solution to the problem, because now people can get root even after it's dropped privs. Not to mention now you cannot restart sshd if you need to, because it has to be pid X. And god help you when the kernel people come up with yet another 'fake' process that runs when the kernel starts, using no memory but taking up a pid.

      And there is functionally no difference between being able to change to any user except root and being able to change to root. If you can change to the sysadmin's non-root account you can get root trivially by trojaning 'su', or, if he's very paranoid, by trojaning his shell.

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close