Re: disabling root and olpc passwords
On Feb 4, 2008 8:23 PM, John Gilmore [EMAIL PROTECTED] wrote: It's easy to get confused about this -- the particular implementation strategy for update.1 has changed several times. (Indeed, I might have it wrong, but I rest assured that if so, someone will correct me.) See http://dev.laptop.org/ticket/5537, which seems to be the master ticket for this issue (there are lots of dups). You've got it right. The shifting strategy was an artifact of the shifting schedule for update.1. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Gary Oberbrunner wrote: subbukk wrote: sftp and scp both require receiver to share login password with sender. nc doesn't. It just reads/writes bytestreams from/to network sockets. E.g. You can transfer sub-directories across machines with : [EMAIL PROTECTED] $ nc -lp | tar xzvf - ./src [EMAIL PROTECTED] $ tar czvf - ./src | nc -q 10 192.168.1.2 without exchanging passwords. It's extremely cool, and good for hardcore users, but most people don't have the level of understanding needed to use netcat effectively. Plus ftpd/sshd are standard daemons; netcat can be daemonized too but it requires some hand-coding. Uh, well ssh/scp is not exactly the naive user's best friend as far as ease of setup. -- Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
subbukk wrote: sftp and scp both require receiver to share login password with sender. nc doesn't. It just reads/writes bytestreams from/to network sockets. E.g. You can transfer sub-directories across machines with : [EMAIL PROTECTED] $ nc -lp | tar xzvf - ./src [EMAIL PROTECTED] $ tar czvf - ./src | nc -q 10 192.168.1.2 without exchanging passwords. It's extremely cool, and good for hardcore users, but most people don't have the level of understanding needed to use netcat effectively. Plus ftpd/sshd are standard daemons; netcat can be daemonized too but it requires some hand-coding. -- Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
On Feb 4, 2008 11:37 AM, subbukk [EMAIL PROTECTED] wrote: On Sunday 13 Jan 2008 4:48:08 am Mikus Grinbergs wrote: The 2008-1-12 OLPC News says ... so that we can finally disable the root and olpc passwords. The way I have my G1G1 system set up (I have no wireless) I *need* to ftp in. For that, I have set a password for olpc. It would be ok with me to set up a different user+password for ftp, but would *not* be ok for password support to be disabled. Mikus, Just what exactly do you need ftp for? There are much better alternatives for transfering files. You may want to use nc (from netcat package). It is smaller, easier and has none of the user/password/double-port stuff. snip Or better yet, use sftp or scp. Your olpc user gets his/her own keys generated when you first start up. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Just what exactly do you need ftp for? There are much better alternatives for transfering files. Works for me. I forget how long I have had my house LAN - must be over a decade. Back then, I decided upon the process I would use to communicate from the main (OS/2) system I work on, to the additional systems on the LAN. Ftp is how ALL of my systems are set up. Until I want something ftp does not provide, I see no need to install (and learn to use) alternative ways to ship files between systems on a LAN. I posted because there appeared to be a regression (regarding asking for passwords) in the OLPC behavior -- that exists regardless of how I described happening to notice it. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
On Monday 04 Feb 2008 10:11:02 pm Chas. Owens wrote: Or better yet, use sftp or scp. Your olpc user gets his/her own keys generated when you first start up. sftp and scp both require receiver to share login password with sender. nc doesn't. It just reads/writes bytestreams from/to network sockets. E.g. You can transfer sub-directories across machines with : [EMAIL PROTECTED] $ nc -lp | tar xzvf - ./src [EMAIL PROTECTED] $ tar czvf - ./src | nc -q 10 192.168.1.2 without exchanging passwords. Very handy for machines in a mesh. sftp/scp would be an overkill for such purposes. The 20KB nc is one of those utilities that makes you wonder how you ever managed without it :-). Subbu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
On Sunday 13 Jan 2008 4:48:08 am Mikus Grinbergs wrote: The 2008-1-12 OLPC News says ... so that we can finally disable the root and olpc passwords. The way I have my G1G1 system set up (I have no wireless) I *need* to ftp in. For that, I have set a password for olpc. It would be ok with me to set up a different user+password for ftp, but would *not* be ok for password support to be disabled. Mikus, Just what exactly do you need ftp for? There are much better alternatives for transfering files. You may want to use nc (from netcat package). It is smaller, easier and has none of the user/password/double-port stuff. Subbu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
On Feb 4, 2008 12:59 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: I posted because there appeared to be a regression (regarding asking for passwords) in the OLPC behavior -- that exists regardless of how I described happening to notice it. It is not a bug. Use 'passwd' to set a password. Problem solved. Can we move on? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
I posted because there appeared to be a regression (regarding asking for passwords) in the OLPC behavior -- that exists regardless of how I described happening to notice it. The theory is that in update.1, the olpc and root accounts will come disabled (locked with a password that nobody can type). However, you can change the password by becoming root (using sudo, or su, or root autologin on the tty1 console, or the Become Root button in the terminal activity). Then just use the passwd command to set whatever password you like. After that, you can start incoming ssh and/or FTP sessions using your newly set password. It's easy to get confused about this -- the particular implementation strategy for update.1 has changed several times. (Indeed, I might have it wrong, but I rest assured that if so, someone will correct me.) See http://dev.laptop.org/ticket/5537, which seems to be the master ticket for this issue (there are lots of dups). John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Albert Cahalan wrote: Bernardo Innocenti writes: What we're actually doing is just to disable them in the default installation so that malicious activities cannot login as root or olpc and basically own the system. This is NOT needed at all. I wrote and tested an /etc/pam.d/su modification that will prohibit all non-wheel users from getting su to work. What use is it if an application can login, su or sudo as user olpc with no password and _then_ su to root? You can close all the open doors one by one by ruling out logins with empty passwords like ssh does, but then what would be the difference between an empty password and no password at all? Captain Obvious just told me that on any UNIX system, setting an empty password should enable a user to login without typing a password, while disabling the password should instead disable logins by that user. The ssh default of not accepting empty passwords is just a bit too paranoid for some scenarios, and not paranoid enough for others (why not also disallow stupid passwords? :-) Apply both if you wish, but either alone will do nicely. There are other ways too, like SE Linux. While I would certainly consider improvements, what's wrong that we're trying to fix with this simple solution we already adopted? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
On Jan 13, 2008 6:59 PM, Bernardo Innocenti [EMAIL PROTECTED] wrote: What use is it if an application can login, su or sudo as user olpc with no password and _then_ su to root? Fixed by chmod'ing su and sudo 770 and then chgrp to olpc. You can close all the open doors one by one by ruling out logins with empty passwords like ssh does, but then what would be the difference between an empty password and no password at all? There isn't one. Captain Obvious just told me that on any UNIX system, setting an empty password should enable a user to login without typing a password, while disabling the password should instead disable logins by that user. The ssh default of not accepting empty passwords is just a bit too paranoid for some scenarios, and not paranoid enough for others (why not also disallow stupid passwords? :-) Because unhashed versions of passwords are not stored, so password stupidity can not be assessed at that point. While I would certainly consider improvements, what's wrong that we're trying to fix with this simple solution we already adopted? Still would be a good idea to do the thing with sudo and su that I mentioned earlier. -ffm ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Bernardo Innocenti writes: Albert Cahalan wrote: Bernardo Innocenti writes: What we're actually doing is just to disable them in the default installation so that malicious activities cannot login as root or olpc and basically own the system. This is NOT needed at all. I wrote and tested an /etc/pam.d/su modification that will prohibit all non-wheel users from getting su to work. What use is it if an application can login, su or sudo as user olpc with no password and _then_ su to root? No use, but the application can't do that, so the point is moot. That rule will block an su to/from any UID. Note that I did not use pam_wheel, which fails to protect user olpc. I used pam_succeed_if to require the wheel group. This is even easier: chown root:wheel /bin/su chmod 4550 /bin/su ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
disabling root and olpc passwords
The 2008-1-12 OLPC News says ... so that we can finally disable the root and olpc passwords. The way I have my G1G1 system set up (I have no wireless) I *need* to ftp in. For that, I have set a password for olpc. It would be ok with me to set up a different user+password for ftp, but would *not* be ok for password support to be disabled. Also, I don't believe in the political correctness of not using root. I do need to install/remove/change things as root, and *strongly* prefer not to use 'sudo' for that -- I log in as root, and am willing to take the risk of committing a disastrous mistake. Here, too, having a password seems natural to me. I agree with the aim of making the OLPC simple to use, but please don't take passwords away entirely. mikus p.s. I presume the existing 'passwd' command was taken from Fedora. It is too paranoid, forbidding too_short passwords, too_homogeneous passwords, too_similar passwords, etc., etc., etc. Such rules may be needed for a datacenter - but for a schoolroom? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Mikus Grinbergs wrote: The 2008-1-12 OLPC News says ... so that we can finally disable the root and olpc passwords. The way I have my G1G1 system set up (I have no wireless) I *need* to ftp in. For that, I have set a password for olpc. It would be ok with me to set up a different user+password for ftp, but would *not* be ok for password support to be disabled. Also, I don't believe in the political correctness of not using root. I do need to install/remove/change things as root, and *strongly* prefer not to use 'sudo' for that -- I log in as root, and am willing to take the risk of committing a disastrous mistake. Here, too, having a password seems natural to me. I agree with the aim of making the OLPC simple to use, but please don't take passwords away entirely. mikus p.s. I presume the existing 'passwd' command was taken from Fedora. It is too paranoid, forbidding too_short passwords, too_homogeneous passwords, too_similar passwords, etc., etc., etc. Such rules may be needed for a datacenter - but for a schoolroom? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel Typical Linux practice is the following: 1. One *never* allows remote shell login as root -- *ever* -- even behind a firewall. One allows only *one* user in the wheel group to log in to a shell account, and then *only* via ssh. 2. When root access is needed, sudo is used, with the least permissive mode possible. 3. ftp is done using sftp and/or scp. For Windows clients, there's PuTTY. Anything less than this level of security is a bad habit -- a *very* bad habit. Please don't encourage such habits, or ask the open source community to cater to them. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Mikus Grinbergs wrote: The way I have my G1G1 system set up (I have no wireless) I *need* to ftp in. For that, I have set a password for olpc. It would be ok with me to set up a different user+password for ftp, but would *not* be ok for password support to be disabled. No problem: just set a password with passwd for either root or olpc. You could even create new users if you want to. Only, be careful when running the olpc-update script: it will reset all your changes to the OS. Also, I don't believe in the political correctness of not using root. Me neither. I login as root as much as I like on my computers :-) I do need to install/remove/change things as root, and *strongly* prefer not to use 'sudo' for that -- I log in as root, and am willing to take the risk of committing a disastrous mistake. Here, too, having a password seems natural to me. Sure. To me to. You and me are clearly not the kind of audience for which we had to disable the passwords. Thus, you're free to re-enable them. I agree with the aim of making the OLPC simple to use, but please don't take passwords away entirely. You seem to be under the impression that we compiled-out the ability to set passwords in the system. That is not true. What we're actually doing is just to disable them in the default installation so that malicious activities cannot login as root or olpc and basically own the system. p.s. I presume the existing 'passwd' command was taken from Fedora. It is too paranoid, forbidding too_short passwords, too_homogeneous passwords, too_similar passwords, etc., etc., etc. Such rules may be needed for a datacenter - but for a schoolroom? Here at MIT the XOs have public, globally accessible IPs, and the logs are full of ssh connections trying random passwords. In deployments, we're using primarily IPv6 and I was under the impression we will not need NAT gateways. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
On Jan 12, 2008 9:17 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: If the system notices that passwords are similar, there's at least some chance one guy knows another guy who then tells someone in upper management that if the system is able to find similarities between passwords, they surely are not stored with a cryptographically secure hash function. Not true, since most users are required to enter the old password before changing their password. Now if it were to notice that the password you are using now was the same as 6 months ago (assuming change every month) that _would_ indicate poor security. -ffm ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Mikus Grinbergs wrote: The way I have my G1G1 system set up (I have no wireless) I *need* to ftp in. For that, I have set a password for olpc. It would be ok with me to set up a different user+password for ftp, but would *not* be ok for password support to be disabled. No problem: just set a password with passwd for either root or olpc. You could even create new users if you want to. Only, be careful when running the olpc-update script: it will reset all your changes to the OS. Also, I don't believe in the political correctness of not using root. Me neither. I login as root as much as I like on my computers :-) I do need to install/remove/change things as root, and *strongly* prefer not to use 'sudo' for that -- I log in as root, and am willing to take the risk of committing a disastrous mistake. Here, too, having a password seems natural to me. Sure. To me to. You and me are clearly not the kind of audience for which we had to disable the passwords. Thus, you're free to re-enable them. I agree with the aim of making the OLPC simple to use, but please don't take passwords away entirely. You seem to be under the impression that we compiled-out the ability to set passwords in the system. That is not true. What we're actually doing is just to disable them in the default installation so that malicious activities cannot login as root or olpc and basically own the system. p.s. I presume the existing 'passwd' command was taken from Fedora. It is too paranoid, forbidding too_short passwords, too_homogeneous passwords, too_similar passwords, etc., etc., etc. Such rules may be needed for a datacenter - but for a schoolroom? Here at MIT the XOs have public, globally accessible IPs, and the logs are full of ssh connections trying random passwords. In deployments, we're using primarily IPv6 and I was under the impression we will not need NAT gateways. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Carl-Daniel Hailfinger writes: On 13.01.2008 01:45, M. Edward (Ed) Borasky wrote: Typical Linux practice is the following: 1. One *never* allows remote shell login as root -- *ever* -- even behind a firewall. One allows only *one* user in the wheel group to log in to a shell account, and then *only* via ssh. Which is almost as unsafe as using root directly. It's exactly as unsafe, unless you count the obscurity value of the non-root account. Note that olpc will not be obscure. 2. When root access is needed, sudo is used, with the least permissive mode possible. And once you start installing software globally via sudo, the account from which you called sudo to install software is (in almost all circumstances) effectively root. Same goes for bootloader configuration. Thank you! The sudo people sure do market that tool very well. I was starting to wonder if everybody had gone insane. No, there is no magic bullet for security, and sudo doesn't even help. (excepting rare cases involving remote logging and multiple poorly trusted admins -- as may be the case with employees being paid to babysit a server) Anything less than this level of security is a bad habit -- a *very* bad habit. Please don't encourage such habits, or ask the open source community to cater to them. Actually, I would consider the belief that sudo makes things unconditionally safer to be mostly equivalent to the belief that a personal firewall (which is not a firewall) makes things unconditionally safer. IMO, use of sudo should be discouraged because it gives people a false sense of security. I strongly agree. Also, sudo is 146K. Ditch sudo, save space, and improve security all at the same time. Many people interpret complicated or work-intensive interfaces as damage and work around them. Often the workaround not only neutralizes the intent of the original interface, it actually makes things worse from the perspective of the person who tried to impose the interface on them in the first place. Yep. Firefox is starting to get me clicking OK to everything because it throws up a pair of dialog boxes for most https sites. Lovely. If there were actually a serious problem, I might not spot it. Firefox is crying wolf, with predictable results. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: disabling root and olpc passwords
Bernardo Innocenti writes: What we're actually doing is just to disable them in the default installation so that malicious activities cannot login as root or olpc and basically own the system. This is NOT needed at all. I wrote and tested an /etc/pam.d/su modification that will prohibit all non-wheel users from getting su to work. Somebody else pointed out the simple /bin/su permissions that that would do the exact same thing. Apply both if you wish, but either alone will do nicely. There are other ways too, like SE Linux. For the PAM solution, the top 3 lines of the file should be: #%PAM-1.0 auth sufficient pam_rootok.so auth requiredpam_succeed_if.so use_uid user ingroup wheel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
