Another Fedora Decision

Home » CentOS » Another Fedora Decision
CentOS 238 Comments

So, probably some of you, at least, follow Fedora, perhaps in part to see what new desktop user oriented decision will make it into the next version of RHEL/CentOS.

You may have noticed how if Fedora, by some odd scheme, deems your password unworthy, you have to click Done two times.

So, the latest Ananconda takes this one step further. Passwords that the system considers weak will no longer be allowed. While this will probably only be a minor inconvenience, (add 3 bangs to the end or something equally meaningless), a few on the fedora-testing list, including myself, think it’s just one more solution seeking a problem.

At present, I don’t know where one can lodge a protest. Hopefully, someone will care enough to file a bugzilla RFE.

Others may think it’s a great idea–at last, users can’t install with a password of 1234.

Anyway, as part of their push for it is that no one minds it, thought I’d mention it here, as many of the desktop oriented decisions get into Fedora, then into RH and it’s already too late.

238 thoughts on - Another Fedora Decision

  • OP’s point is that probably in RHEL8 you won’t be able to do even that anymore. While I personally think this is a good idea, this has some potential to maybe cause trouble or inconvenience down the line, with regards to automated installs, broken kickstart scripts, various company policies regarding the root password, etc. I guess there are sensitive scenarios out there.

    So if any CentOS user think they can be hurt by this change, they should do something about it now, rather than bitch about compatibility breakage when RHEL8 comes out in a couple of years. :-)

    HTH, :-)

  • While I personally think this is a good idea, this has

    Kickstart installs with an already encrypted password in the kickstart file would not be affected. The only way the installer could know how weak the password was would be to spend the time to guess it.

  • Well, protesting here would be meaningless .. as is protesting systemd here. CentOS-8 will have whatever is in the RHEL-8 source code, exactly as it is in that source code minus branding. Just like CentOS-2.1, 3,
    4, 5, and 6. Our goal is to rebuild the source code exactly, bugs and all. We want all the behaviors and the experience to be identical in every way.

    If you want to effect change before it gets in RHEL, then Fedora is the place. If you want to get it changed in CentOS, then buy RHEL and providing feedback there is the way. We are, by design, exactly as Red Hat pushes the RHEL source code.

  • Hi Johan,

    If your brother in law doesn’t see that the virus argument doesn’t apply to the question of whether or not to choose strong passwords maybe he shouldn’t be a software developer in the first place.

    Strong passwords don’t protect against viruses, phishing etc. pp., that is true. But having weak passwords opens a plethora of other attack vectors beside that, and as for instance the iTunes hack shows there *are* real-world scenarios where passwords are attacked successfully. Just put an SSH server on a public IP and wait for a day, and you’ll see how many.

    Regarding the original issue, I don’t see where requiring users to enter strong(ish) passwords in the GUI installer at installation time could do any harm except a minor inconvenience for some people. Kickstart is not affected, so automated installs won’t break, and on the other hand the use of weak passwords may be reduced a bit by the change. I’m all for it.



  • No, this is great. We do like CentOS for what it exactly is: binary replica of RedHat Enterprise. And even if we complain sometimes here on CentOS list about this or that, we do not (at least I do not) expect it changed in CentOS the way we like it, making CentOS different from RedHat Enterprise. It is more like “letting our steam out”, so ideally we probably shouldn’t do it at all. However, password thing thread (which I
    didn’t add to yet) just reminds all of us about good practices. So, this discussion (without any changes expectations in CentOS) may still be appropriate and helpful.

    Thanks to CentOS team for the great job you guys are doing! (we always have that in mind, rarely say it though)


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Personally, from the outside looking in, this all smells of a pointy haired boss directive that the devs are trying to cover their collective asses from. Of course, my corporate days are long behind me so perhaps things have changed. Equally it could be simple incompetence by highly strung people that do not like being criticised for an ill-considered hasty decision but who actually have no evidence to support it.

    I have to go off now and find a nice bone bed to lie down in; and fossilize.

  • Java developer, huh. Be it me I would definitely mention that java related stuff adds its very noticeable share to compromises. From sysadmin point of view java is a disaster: mostly you are executing someone’s else code
    (java applet from remote …) on your own machine. Of course, I know my opinion is highly amplified by my not getting along with java language as opposed to multitude of other languages I get along with. Tell him to look some time into SSH log and count unsuccessful connection attempts. And I’m sure analogy like not locking your apartment door just because your building door is locked, or better though because on local radio they announced no thieves are roaming in your town – is kind of weak reason. Even java developer brain should grasp it (no, it was intended as a joke, not as offense. I do use and admire brilliant software written in java!
    And I’m grateful to brilliant java programmers written software I can not write!)

    Going back to password discussion. Interestingly, I never was bugged by installer for using weak password (which I don’t). Still, I consider it counter productive to force any requirements onto people who do not care about the original goal of them (security in this case). I remember in the past some sysadmin discussion about forcing your users to use very sophisticated passwords (passphrases we will be saying these days) and even worse: forcing them to change passwords often. Basically, the most sane view (IMHO) is: person’s ability to memorize and type password is most important. And users will change password promptly when there is reason to suspect the password was compromised – users are much more cooperative if you don’t put on them unnecessary burden. If you do sysadmin job well it will be remote compromises that you will deal with
    (when user’s password got stolen elsewhere, say when user logged into your server from compromised machine). Thus running multi-user machine under assumption bad guys are already in is right attitude. Keep the machine local exploit free. Have good backup (so you can restore files of unlucky user if his/her files are obliterated by intruder). And watch what is happening on the machine.

    Do I advocate for weak passwords? No, by no means. However, it is really unreasonable to think that you can make system such that it will force people not do stupid things (use bad passwords). So, I for one do like what passwd command does now: it warns one that the password is weak when typed first time, and accepts that weak password if one insists and types it second time. Person willing to do bad thing will find the way around any protection to do it, yet even worse way.

    Just my $0.02


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • So who do you believe is driving RH corporate? Why are they expending the effort to do this?

    The answer is clear to me: general security principles. By the time EL8 comes out, we’ll have had ~3 years of warnings under EL7 that weak passwords would not be tolerated, and they’re finally disallowing them. Good!

    (More like 6 years, actually, because EL6 gives a red warning bar for weak passwords.)

    Let’s flip it around: what’s your justification *for* weak passwords?

    We use them here temporarily during setup, but we lock the system down with a secure unique password before deployment. Switching to something more secure really is not that burdensome.

    Why would there be? The trend in security is clear: keep up or get run over.

    The only question is how quickly forward we proceed, not which direction “forward” is.

    RHEL has been moving forward pretty darn slowly. The current system in EL7 allows *appallingly* bad passwords. Passwords that can be cracked in reasonable time scales even with SSH’s existing rate-limiting.

    That could be because there is no rational reason.

    Got one? Lay it on me. Please include a description of the threat model where a password like byrnej123 should be allowed, which *is* allowed in EL7, as long as root is setting it and says “Yes, I really am sure I want such a dreadfully easy to crack password.”

    While I’ve got the floor, I would like to encourage everyone to send mail to to protest tomorrow’s sunrise.

    Rationale: Melanoma is bad.

    Hmm, yes, let’s hold public committee hearings for every technical change. The resulting bureaucratic mire will surely usher in the Year of Linux!

    What secret motive *could* there be?? The current security policy is weak, and this change fixes that. End of story.

  • It’s hard to not endorse everything you are saying. As far as motive is concerned, it is not that secret. Security. RedHat doesn’t like poorly administered machined with RHEL linux get hacked, then many voices saying saying in the internet: RHEL Linux is not secure, RHEL Linux machines are getting hacked. Even though the reason is not what it sounds like.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Wrong point. Wrong focus. Ultimately it is for the deployer (and the user if Root) to determine. To suggest otherwise is pure arrogance.

    M$ users do not own their machines. M$ does. M$ determines what they can do and what data M$ secretly collects on them, stores on the machine and prevents the user viewing. Seems like another move towards emulating M$.

    If testing then a one character password is very acceptable to me. Why should some arrogant nutter impose an arduous ultra secure password when a simple one character password will suffice ? Who knows the machine, the deploying environment and the circumstances better ? The user or some anonymous and arrogant nutter perhaps many thousands of miles (or kilometers) away ?

    Remember machines should be working for the convenience of Humanity –
    not for the convenience of anonymous nutters who know absolutely nothing about the user’s work situation ! Generally having strong passwords is good however generalised circumstances should never be forced down the throats of loyal users. An English (as in England, Europe) saying is:-

    Rules were made for the guidance of wise men, but for the obedience of fools !

    If everyone is willing to donate USD 1, then perhaps we could lend him to M$ where security is so lax he could do some enormous good.

    No need to waffle Warren. You’ve lost this one :-)


    Paul. England, EU. Je suis Charlie.

  • ‘anonymous nutters’? I guess those people on the cited mail lists are using fake names. Given you’re carrying on about being English, maybe you should contemplate the slander, libel and defamation laws in that country as well as in other countries where your post may be being read.

    I don’t think it’s Warren who’s waffling. I certainly don’t think the people on the referenced mail lists are anonymous, or nutters.

    And just to be 100% clear, you’re certainly not speaking for me.


  • Whereas I agree with you… Well, I tell my users when they set password after I created account for them: the most important is that you can memorize and type your password. I myself, however use rather strong password (knocking on wood), and was never bugged by “weak password”
    warning. Being sysadmin, and “paranoia” is in sysadmin’s job description, I tend to have all passwords different, neither of my regular user, or root passwords ideally should never repeat anywhere, even on different machines I administer. So I imminently am using encrypted password storage. These days it is keepassx.

    Just my $0.02


    PS I don’t like though policies invented by bureaucrats having no technical knowledge serving only to cover their backsides, like in National Laboratories they require one to change password every 6 Months, and password should never be anything you used in the past. This doesn’t serve security, and is counter-productive. This policy for me indicates that they declare explicitly that they maintain security of their systems not too well, as a results of which your password likely can get compromised…

    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Or, you might similarly ask what is your justification for not getting up at 5 AM, going to the gym and swimming 20 or 30 laps every morning. The answer might just be that you are lazy, but should a software vendor make their code stop working for you because they think you aren’t working hard enough?

    Les Mikesell

  • I assume, you may have your own list but once you asked I’ll mention off the top of my head what I’ve seen (no, these are not happened on machine I
    administer – knocking on wood ):

    1. machine compromised elsewhere, user password (via keylogger or malicious SSH client) or secret key gets stolen; cyber criminal connects to my server with credentials on my user

    2. after he is in: elevation of privileges through some local exploit. As I tend to have nothing to be exploited on multi-user machines (and run them under assumption bad guy is already in), this normally doesn’t happen to me, but I help sometimes to sweep up mess and do forensics when that happened to someone

    3. Independent on the above: just blunder when you are doing administration. I have seen admin helping a user (who was on the phone)
    change his password. And he accidentally in

    passwd username

    stuck enter between the above two words (!). Which ended up in changing root password on machine to very weak one he passed that person over the phone. When that didn’t work (good hint that that was not that user’s password that was changed!), he just changed it again. Then intruder just walked as root through open door (that weak password was one of the top four in cracker’s dictionary).

    4. Not updating the system, or having vulnerable services – I have seen these as well

    5. Weak root password should be on the list, but practically only the ones on the top of password cracking dictionary are… Anyway, I do (or I like to think that I do) have strong root passwords. Nevertheless, I always have measures to thwart dictionary attacks from the network (as some of my users may have weak passwords, not the ones on the top of dictionary though I bet)

    … This list goes on, someone can continue. Most of what I see (like the list above) I would classify as poor system administration. The last has nothing to do with how well RedHat puts together and patches their system. So I can understand them being less than willing to have RHEL hacked due to that. However, to think that you can force one to maintain his system well is utopia. So, even though I understand their reasons, I am sceptical they will find panacea.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • The new rules are:

    1. At least 8 characters.

    2. Nothing that violates the pwquality rules:

    Are you telling me you cannot memorize a series of 8 characters that do not violate those rules?

    I’m the first to fight boneheaded “password security” schemes like a required change every N weeks, but this is not that. Spend a bit of time, cook up a really good password, and then use it for the next several years. That amortizes the cost of memorization to near-zero, greatly reducing the drive to write it down in an insecure place.

    That doesn’t really apply here. Any password you have to type into a GUI is going to have to be something you can memorize. Password managers are for things you access *after* you are logged in.

    (Another gripe of mine: this recent trend toward using some “cloud” login as your OS login. Apple, Microsoft, and Google are now all doing this! This perforce requires me to weaken a password with a cloud-sized attack surface (i.e. frackin’ huge) to the point that I can memorize it. Before this change, I was using huge random passwords and 2FA. That doesn’t work any more in a world where the OS now requires my cloud password every time it wants elevated privileges.)

    Presumably you have already worked out a good password, and memorized it.

    This change is not going to enforce uniqueness per server.

    (Though, if this server will be used via SSH, it might be a good idea to do that anyway. SSH keys — optionally with passphrases — are more secure than even quite a long human-memorizable password. Disable password auth and use keys.)

  • Yet, the “fools” are so inventive, they often find a way around rules.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • When the consequence of widespread bad security is botnets and all the ills that derive therefrom — DDoS armies, spam, etc. — then yes, I think we do need to raise the industry’s overall level of security.

    At risk of bringing out some *actual* Internet nutters, the question of minimum password security levels is directly analogous to that of vaccination. When a large population stops vaccinating, we start seeing previously-defeated diseases coming back, like the measles outbreaks in California and rural Australia:

    Polio was almost completely eradicated, but it’s starting to come back in the middle east after the CIA used a fake vaccination campaign as a pretext to try to get into bin Laden’s Pakistan compound:

    I believe personal freedom should count quite highly in policy discussions. But, when your failure to protect yourself endangers me, it stops being a question of personal freedom.

    Practice safe hex!

  • I know its hard to believe, but you are not the only one using this OS. There are a broad range of users with a broad range of experience using the OS in a broad range scenarios. One important group is new users with limited experience and knowledge about security. This is an important group to protect. More experienced users understand this and put up with, or work around, the occasional inconvenience. This is not arrogance, this is about being a responsible member of a community. It is important for all of us to encourage (and discuss)
    good security practices, as well as discourage (and refute) poor practices. Ultimately, this make our community a safer place.

    It is my, perhaps naive, hope that members of our community are Always Learning about good security practices and emerging threats to the OS.

    The root password is close to, if not actually, our last line of defense (SELinux helps us here by the way). Using a one character password is problematic if you are connected to the internet, for example, if you are _testing_ the OS and want to run updates after the install. This is problematic since, by default, new installs typically allows SSH access and root logins over SSH. Yes, firewalls help, but they need to be configured correctly, and there are subtle tricks that sophisticated attackers can exploit to subvert poorly configured firewalls. If you really want to do this, I’d suggest running your test system in some kind of DMZ to prevent any exploit cascading into the rest of your network. It may just be easier to pick a “good” but easy to type root password that you use for all your test machines. Also, its a good idea to make sure you always turn off your test machines when not in use, and to disable them once you are finished testing (so they can’t be accidentally turned on in the future).

    Hope this helps.


  • Didn’t cite any mailing list. One can not defame an anonymous nutter/expert/genius/fool. Can’t be slander because that is oral defamation.

    When the changes (a.k.a. improvements) are introduce, just how many users will be aware of the identities of those who promoted and implement those changes ? Very few, if any. Hence ‘anonymous’ is definitely justified in that context.

    Nutters seems justified because a wise decision maker will always permit informed users to make their own choice.

    Writing for myself is sufficient. This list does not yet circulate audio messages.

  • Whether anonymous or not, they continually show that they have no idea of a work situation. Each time we work around it.

    As I understand it, the rationale is because RH allows SSH root login by default. I’d rather they change that, but I also want to have millions of dollars and be admired by everyone.

  • The Taliban were created and funded by the USA, using the Pakistani intelligence service, to give the Russian invaders of Afghanistan a bad time. Bin Laden was a frequent guest of honour at USA military bases in the US of A.

    Inoculation against illnesses is important.

    As for security, the cess pit is weak security not on Linux, BSDs and others etc. but on M$. It seems to be incredibly easy for one malicious person to launch attacks from machines they control all over the world –
    and those machines just happen to be running M$. Breaking into M$
    machines seems to be t-o-o easy so I suspect it is not password weaknesses that are being exploited !

    Encourage good security but don’t force it down our throats !


    Paul. England, EU. Je suis Charlie.

  • This is not correct and a dangerous assumption to make about real and current threats.

    Your security practice, as you have described it, is poor. If you have been compromised, you may not be aware of it. A compromise of your systems weakens the whole community.


    Kahlil (Kal) Hodgson GPG: C9A02289
    Head of Technology (m) +61 (0) 4 2573 0382
    DealMax Pty Ltd

    Suite 1416
    401 Docklands Drive Docklands VIC 3008 Australia

    “All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use a hammer.” — IBM maintenance manual, 1925

  • Perhaps a topic for the CentOS Wiki entitled Basic Security on Your New Machine ?

    Surely the whole idea is to prevent nasty things getting in.

    Disable FTP. Change SSH ports. Restrict access to sensitive parts from known IPs. Run Logwatch or similar (and amend the reports using /etc/logwatch …). Read the logs. Allocate file and directory permissions to users lacking any log-on ability.

    There is a lot that can be done.

    But if one is doing things on a isolated machine unconnected to anything why the password aggro ? Best never to speculate when attempting to justify a hash and arrogant policy of DO WHAT RHEL DEMANDS. I prefer a clear warning and then let the user make an informed choice. After their first hacking they will not make a similar mistake again.

    Then block it as part of the installation process and let the user open what they think they need. Not use if you are correct about SSH. Root usually (if I remember correctly) needs to be permitted.

    Again another opportunity for a good CentOS Wiki article. A basic firewall setup. Then a series of examples: to achieve this, do that. Obviously good and clear explanations are needed to enable impeccable understanding of the firewall logic.

    Yes help the new users. Perhaps even a CentOS NewUsers list devoid of all the more technical things. It could cater for single machine users.

    Not really sure what a (USA military) DMZ looks like. Security has always been my highest priority. “When in doubt, lock ’em out” is my motto.

    Unnecessary in my working environment. I write and test virtually even day, 7 days a week. No machine, test or production, has unrestricted access to/from the Internet. Unused ports are blocked. Unused applications are removed or disabled. SSH is allowed from only 3 IPs. Instant IP blocking for suspicious activity has been a basic component for the last 3 or 4 years, or longer. It was the first security enhancement I programmed.

    To save electricity equipment is turned-off when not in use.

  • They lack general knowledge of the ‘real’ computer world. To them it seems like a childish game.

    How can a remote user log-on for the first time, if not via SSH ?
    Perhaps the installation process should permit the installer to select a non-standard SSH port at installation time ?

    …… and on first log-on the user is forced to change the password and also to change the originally SSH port ?

    It would have been nice if the ‘anonymous’ to me people on another RH
    related list had popped into CentOS and sought ideas, opinions and comments ….. that is what ‘team work’ is about :-)

  • A DMZ in this context is a network that has been isolated from the rest of your local network. You can access it from your local network, it can access the rest of the world, but it can’t access your network. The idea is that, if a machine in the DMZ is compromised, it can only access other machines in the DMZ.

    Kahlil (Kal) Hodgson GPG: C9A02289
    Head of Technology (m) +61 (0) 4 2573 0382
    DealMax Pty Ltd

    Suite 1416
    401 Docklands Drive Docklands VIC 3008 Australia

    “All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use a hammer.” — IBM maintenance manual, 1925

  • What is incorrect ? The fact that one person can control many computer systems – home and business – all around the world ?

    That the same person can launch exactly the same attacks on my mail servers and the same attacks on my web servers from different machines all around the world ?

    That the machines being used for the attacks just happened to be running M$ ?

    That every day I witness the attacks on my systems ?


    I really do think I would because of the systems I run. Please do not judge my standards by standards you may be familiar with.

    I’m am sure that is not true.

  • They appear to be an increasing source. Those and Vietnam are currently popular. So I block the data centres/coloc IP ranges.

    Blocking of individual IPs is automatic and is for all ports. It usually lasts for about 4 to 6 weeks. Manual blocking is usually of IP ranges and usually permanent but restricted to ports 25 or 80.

    I want is a quiet life :-)

  • I suspect list subscribers are inclined to view your standards (or lack thereof) in the light of your rubbish superiority-complex attitude.

  • its *very* annoying that the soho internet gateway/router market uses the term “DMZ” for the target of default port forwarding rules, nearly the exact OPPOSITE of what a proper DMZ is.

  • Thanks. Now I know. That sort of operation can be done via the router and by selecting a wifi option on the same router (Asus RT-AC68U). Wifi is off by default.

  • OK, folks. You’re doing a great job of describing the current milieu with a rough description of some best practices.

    Now how about some specific sources you personally used to learn your craft that we can use likewise?


  • What matters to me is my systems are secure. I have too much to loose if any part if compromised. That is why security remains top priority.

  • An Asus RT-whatever is a home internet gateway, not a proper firewall router, and it has no provision for a proper DMZ as it doesn’t have a port for it. This has *nothing* to do with wifi.

    implementing a proper DMZ requires a firewall router with multiple zones, at a minimum WAN (internet), LAN (your regular network), and DMZ, used for your public facing internet servers. The DMZ uses its own network switch (or VLAN) separate from your LAN switch(es), so traffic from LAN< =>DMZ has to go through the firewall router. You define firewall rules such that DMZ servers are blocked from accessing anything on your WAN except specific services they need (if any), but you usually allow systems on the LAN side access to everything on the DMZ side.
    I’ve seen configurations where even LAN to DMZ was tightly controlled, so for example only administrator workstations could SSH into the DMZ

  • Taught myself (as usual). Used Google to find helpful advice from countless other people. Taught myself PHP to do the coding. Use BASH to perform repeated routines.

    Will publish my Exim configuration and associated routines (including the anti-spammer checks etc.) on one of my web sites. And my EXIM
    changes to Logwatch.

    Will add my Apache error routines, support files and reporting routines too.

    How much do you currently know ?

  • The Asus I use for development work is more than a mere ‘home only’
    thing. It is used in small offices and caters for multiple external IP
    addresses. It has wifi that separates visitor traffic from the LAN it controls.

    However I have no wish and no need to play about using DMZs because for the development work I do, I don’t need a DMZ or anything resembling a DMZ.

  • OK, what were the key words you used as search terms?

    I’m sure that would be helpful, especially if others do likewise so we may compare and contrast what was done.

    Enough to know I have a lot to learn.


  • That always depends on what I am trying to do. I start with a problem/project then I research the subject. Its a bit like learning the law.

    My reservation is could a spammer/hacker then use that information to circumvent those anti-spamming/anti-hacking routines ?

    I have lots to learn too. Linux is vast. My time is finite.

    Your answer is a bit like the Irish man who said “If I was going to xxxxxx I would not be starting from here.”


  • Disagree. One does not have to posses some mythical qualifications, or any qualification at all, to write a sensible guide. What is required is knowledge, experience, clarity of thought and expression and a desire and ability to pass-on one’s knowledge to others in a very understandable manner.

    Peer review is obviously beneficial.

    Placing obstacles in the way perhaps explains why this topic may not have been sufficient covered by the CentOS wiki. Just look at what the
    “Qualified” have produced so far on this topic ! Why does one need to be “qualified” by a third party before one can write a good, concise and very informative guide ?

    I think it better if the peer reviewer/reviewers is/are distinct from the author(s). Reviewing one’s own work is often prone to inadvertently overlooking one’s own mistakes.

    It can be a collaborative effort.

  • I’ve learned system administration way back (of course, I do flatter myself by thinking what I’m saying ;-) and still I keep learning new things all the time when I’m doing my job. Unix system administration book was a big thing (big step after computer science degree I got some time before); TrinityOS: a guide to configuring your Linux server for performance, security and manageability by David A. Ranch was a big step I
    can remember from way back. And after you got the basis, keep challenging yourself by doing new things. Of course, there are a bunch of other more specialized books… Not that I consider I mastered this craft, but I
    hopefully maintain my boxes so that they are secure…


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • So many places it makes my brain hurt just thinking about it. Google and Wikipedia will keep you busy for a long while.

    Off the top of my head:

    There are some online “Security Handbooks” around (I think RedHat publish one) which lay some of the basic ground work.

    SANS ( and OWASP ( have some good resources. If you are cashed up, you can even do courses with SANS.

    Reading about the security infrastructure that you are already using is a good idea, often accessible via mysterious things called “man pages”. I learned a lot simply by reading about pam, iptables, and selinux.

    Thinking about you systems from a penetration testing perspective can be helpful. For example, “Always Learning” has just told us that he uses single character root passwords on his testing machines, that he is testing 7 days a week and does not turn off his test machines. A
    pen tester or cracker could use that information to formulate a potentially successful attack strategy.

    Google “free penetration testing tools”. Only use the tools if you own the network or have written permission. Just reading about the tools can give you some insight into attack strategies that you should be defending against. Please don’t try to attack “Always Learning”.

    Download and unpack a copy of rkhunter. Have a look inside. Its just a bunch of bash scripts. Good insight into some surprisingly simple historical attacks.

    Google “linux security hardening”. There are a lot of resources out there. The hard part is sifting out the gold from the crap. Sorry can help much there.

    There are many other people on this list who have a much better grasp on this stuff than me. Hope they chime in.

    Hope this helps,


  • Warren Young wrote:

    The 7 rules listed in this URL seem utterly bizarre to me.

    The first is “Don’t use a palindrome”
    which makes me wonder if the author knows the meaning of this word. I suspect he/she thinks it means “a known word backwards”.

    Of the remaing 6 rules one is optional (“repeated characters”)
    and 3 of the remaining 5 concern similarity to previous passwords.

    Of the remaining 2, one is to avoid short passwords (unspecified), and the other to avoid one’s username.

  • That’s what I would call it (or phrase or sequence of numbers.) When I
    read your post, I thought I was missing something, but some cursory googling indicates that I’m right. What am I missing here?

    (Looking stupid for the sake of everyone who wants to know, because I’m unselfish–and, having been married more than once, have a thick skin).

  • Valeri Galtsev wrote:

    While I admire RedHat, and use CentOS on my home servers, I would expect RH to give priority to those paying for their services, who I imagine are almost all sysadmins of systems with many users. My interests as a tiny user may not coincide with theirs.

    This does not mean that I think there are evil spirits at RH
    trying to disrupt my life. But it does mean that the inconvenience of strong passwords may outweigh any additional security in my case.

  • I’m curious, were you upset when Java (and various other software packages that use SSL) were updated to stop using SSLv3? Surely this would have caused problems with any testing infrastructure that wasn’t open to the world that used pre-generated SSL certificates. The decision to disable it was made by the packagers of the software because of security implications. Sure, SSLv3 still works, it’s just not secure. It’s just some arrogant nutter who thinks that maybe we shouldn’t be using it anymore.

  • I think it well to recall that the change which instigated this tempest was not to the network operations of a RHEL based system but to the ‘INSTALLER’ process, Anaconda. Now, I might be off base on this but really, ask yourself: Who exactly uses an installer program?
    And what is the threat model being addressed by requiring that the installer set a suitably strong password for root? For what purpose?
    Because RHEL sets the sshd on and allows root access over SSH via password by default? Then is not the correct approach to disable that access instead?

    But wait! Is it not true that the network services are not started by default? So, exactly where is the threat? Does it not occur much, much later in the workflow than at the installer? Would it not be more sensible to require root access to start sshd (hummmm. . . is that not a requirement now?) and to ask for the root password at that time. And then of course, you could catch those sneaky people that change the root password after the install is complete.

    Surly, it is when starting network services that then, and only then, one should check that one of the following conditions are true: 1.)
    root access over the network is disabled; 2.) root access over the network is allowed via RSA only; 3.) if root can log in via SSH using a password then the root password must be strong?

    That process seems like something that could be setup in a network init script, upstart system job, or systemd service file without a great deal of effort. Why does arbitrarily requiring ‘strengthening’
    of the root password have to go into the installer program?

    Yes, the alternative approach would adversely impact automatic system restarts. And your point? Is not the easy answer but to disallow root access over the network entirely; or to force the use of RSA
    certs for root logons? Are not these far, far superior approaches to dealing with this issue than requiring a ‘strong’ root password everywhere, all the time, regardless of what purpose the system is used for?

    This change to Anaconda is not security, it is theatre. It is directly equivalent to airport passenger security checks. Totally ineffectual but so intrusive and inconvenient that we have to believe that it works. For otherwise the inescapable conclusion is that we are all fools for putting up with it; and no-one likes to think of themselves as a fool. I call this the ‘Buckley’s Mixture’ approach to social engineering.

    In any case, allowing an eight character password on credentials exposed to public network access is laughable.

  • Go to Visit and view some of the videos of presentations from previous congresses and hackfests. Educate yourself on the threats. Once you see what you are up against then you will have some ideas about what questions to ask. Then you can find the material you need.

  • I don’t think anybody is missing anything. “Palindrome” in this context may not be limited to real words; the author may be suggesting that you not pick your password by picking a real word and tacking on its reverse to make a palindrome, e.g., “password1drowssap”.


  • Dealing with [computer] security for long time I learned this: if factors A, B, and C affect the security, each of them should be tightened to required security level. A mere fact that A on its own provides necessary level of security can not be served as an excuse to leave B and C loose;
    they too should be brought to the same necessary level of security. This becomes a common sense if one takes into account that A might just not do its job even though appropriately tightened – merely due to some bug. This is the basics of security I was taught, and my long experience confirms this is right thing. My apologies if I misunderstood you and my comment is beyond your point.

    Hm. whether or not my system is clever enough to tighten security at some point, I will keep doing my sysadmin’s part by following security guidelines and practices worked out through …hm… about a couple of decades.

    Well, under some circumstances secret key can not be trusted more that a good password (passphrase). I’ve seen these, so I for one do not share widespread opinion that key pairs (or certificates) are more secure that passwords (meaning passwords in general and excluding people stupidity to have weak ones – I an sceptical that you can force stupid person stay safe by creating one or another environment for them – for everybody that is).

    Yes, indeed we both seem to converge you can not force people who do not care to stay safe to stay safe. Even disagreeing with that I understand
    (not that I approve of) the reasons RedHat is going to enforce that.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • 1. HelpOnConfiguration/SecurityPolicy = 2007-04-01

    1(a). Link ‘SecurityPolicy’ = HTML status code 404
    1(b). Link ‘MoinMoin’ = 2007-04-01

    2. HowTos/Security = 2010-02-19 (RHEL 5)

    3. Security = 2014-10-16 and refer to Heartbleed, Shellshock, POODLE

    *** NOTHING about Firewalls (IP Tables) ***

    Perhaps it is a good time for those with harsh attitudes to abandon the practise of dissuading newcomers from contributing to the CentOS
    Knowledge Pool for the ultimate benefit of everyone especially the newcomers, the shy, those whose English may not be ultra perfect and the curious.

    If a newcomer makes a mistake or suggests something which is a good idea but never been done before by the Old Timers, do not destructively criticise their efforts. Constructive criticism is always good but sheer negativity because the newcomer has a different attitude to established methods is detrimental to the CentOS ethos. After all computers always have been (certainly for me) an endless Learning process.

    Inventions should have have occurred if everyone always had exactly the same attitude and beliefs as everyone else. Thinking differently is often beneficial.

    Sympathetic interaction and informed debate is superior to hash words which usually dissuade the newcomers from ever again making suggestions or offering a potentially innovative idea.

    Those who post on this list are probably less than 0.001% of the world-wide CentOS users. Perhaps a CentOS Newcomers List* environment would nurture a wider and better understanding of basic CentOS whilst leaving the Data Centre things, the users of non-existent Clouds
    (actually just another Data Centre) and the technicalities of different RAIDs, motherboards, peripherals, disk speeds etc. to the main CentOS

    * alternative name suggestions: CentOS Learning ? CentOS Basic ?

    The suggested list should have the possibility of linking to web pages to illustrate topics which means, perhaps, being able to forward diagrams etc. for publication on the CentOS Learning web site.

    CentOS Leaning could and should encourage people to submit articles on various aspects of CentOS. Thus providing a continuous educational environment beneficial to all. CentOS Learning is not a competitor to the main CentOS Users List, but – probably for the first time ever – a genuine online learning and exploring asset for those using or thinking of using CentOS (could even team-up with Scientific since it is the same Linux).

    Fedora has not got such a list, so my idea must be good !

    Please excuse any inadvertent errors and misspellings.

  • I think the intent is: “Don’t use a password likely to be included in the list that an attacker would try”. Of course if services would rate-limit the failures by default or at least warn you about repeated failures and their source, brute-force attacks would rarely succeed. But fixing the problem doesn’t seem to be the point here.

  • Which sysadmins do for ages when they configure their machines. And I
    don’t think any system will ever come from system vendor fully prepared to serve anything necessary, and tightened to best requirements (which depend on box designation anyway). So, system vendors can do better, but there always will be need for you to do your sysadmin’s part. Sounds almost like job security. As one of my friends says: all systems suck, and thanks to that got our jobs ;-)


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Whoops !

    Inventions *WOULD NEVER* have occurred if *PEOPLE* always had exactly the same attitude and beliefs as everyone else. Thinking differently is often beneficial.

  • Really? Are vendors not capable of shipping something with good default settings? It seems like getting a new car and having to install a different engine yourself because the factory couldn’t figure out how to do it.

    If that were really true, then you also wouldn’t be able to follow anyone else’s advice about how to do it. That is, if your system really needs to be so different that it couldn’t have been shipped with the configuration you need, then a book couldn’t tell you that either.

    But wouldn’t you rather be doing something new/different instead of just fixing things that should have been done right in the first place?

  • Sounds so I almost have to feel shame for securing my boxes no matter what job vendor did ;-)

    Just a simple example: I have at least 3 classes of boxes configured ultimately different and having very different level of security/fortification. Do you seriously suggest that system vendor will ship all three level of security configurations? Do you seriously think that needing quite high level of security for some box I will not go over all settings influencing it myself? Will you not? We are not Windows admins, we rely on what we configure or check ourselves. And we do take security seriously, so, we do go over everything whether the system vendor does or does not claim they have done that part already (and and claim they did it better than I can do it). If you prefer to delegate what you are responsible for (security of your box) totally to someone else (even as good guys as system vendor is), then I don’t know what to tell you. Yet, I’m sure, majority Unix sysadmins will still do what I do: go over everything themselves. No matter what someone says.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Yes, computers and the way people access them are pretty much a commodity now. If you are spending time building something exotic for a common purpose, isn’t that a waste?

    Yes, 3 seems about right.

    Of course, but only because the vendor does not do it. I think Red Hat’s engineers are capable of it if they wanted to.

    Not sure what you mean by that. Windows is much worse since the configurations tend to be hidden and the ways to do things interactively and scripted are wildly different.

    There are probably still people that take their cars apart to check that they were assembled correctly too. But that doesn’t mean that things should not be shipped with usable defaults.

  • Do I have to take that people who are not sysadmins themselves just hate an existence of sysadmins?

    Here is the difference between us. I refuse to trust something ultimately important which I can check or tune without checking (and tuning if necessary). It will be my laziness. Note, that that I apply to myself. What you do is up to you (and you bear consequences of your decision, and I bare consequences oi mine).

    No, I’m not the driver of my cars, I mean computers. I am a mechanic of racing car competition team, my cars go into competition, and the life of driver riding it depends on me having taken the whole mechanism apart, and making sure nothing breaks and kills driver and hundreds of spectators.

    I really hate these car analogies. They are counter-productive. In your eyes my server is indeed a commodity, which I refuse to agree with pretty much like I refuse to join ipad generation. My ipad would be commodity, but I for one will never trust that ipad and will not originate connection to secure box from it.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • No, I think there are better things for sysadmins to do than fix settings that should have had better defaults.

    So don’t you think it would be a good thing if the thing was built so it didn’t break in the first place? That is, so nobody gets killed running it as shipped, even it they don’t have your magical expertise?

    The point I’m trying to make is that whatever setting you might make on one computer regarding security would probably be suitable for a similar computer doing the same job in some other company. And might as well have been the default or one of a small range of choices. And in particular, rate limiting incorrect password attempts and/or providing notifications about them by default would not be a bad thing. Unless there’s some reason you need brute-force attacks to work…

  • I agree, this is not good.

    Come do as I have done.

    I followed the instructions at
    After I had edited my home page, I copied three pages into subpages of my home page (Be careful to remove any security restrictions.) and edited them as I saw fit. All three of my pull requests have been accepted. I’m working on further improvements to the Download page, at the moment.

    I would love to review the improvements you may make to any page of the wiki.

  • Its about taking personal responsibility for the security of your system(s). Trusting someone else’s settings of what THEY think YOUR
    security should be, is very unwise.

    It is not car disassembly – it is checking the oil level, the benzin
    (petrol), the brake fluid, the window washer liquid, the tyre pressures including the ‘spare wheel’. Pilots of aircraft do exactly the same. It is called a preflight check. Doing that on a new CentOS installation is sensible and, if one cares about security, desirable.

  • How can any SysAdmin (= System Administrator) administer something he or she is uncertain about ? The job of any system administrator is to poke their nose in and ensure everything is absolutely fine.

    No looking or no checking can not provide the necessary reassurance everything is absolutely fine *AND SAFE*.

  • Maybe…. It is at least equally unwise to think that you are the only expert and all the people who are supposed to know what they are doing are wrong. That’s why we have measles again… I’d rather see some real experts set up usable defaults instead of every person doing an install having to second-guess it.

  • Disagree. Ensure of security of the box is sysadmin’s duty. It is in job description. Job to be done.

    I regret I let myself be dragged into car analogy. Once again, I’m not
    “driving” my machines.

    It is possible that system vendor does what you call better job. I do welcome, e.g., “–hitcount” iptables option used in firewall CentOS comes with. (But some may hate that, and I respect their demand for their boxes). This doesn’t mean I will not take a look into configuration at least once, and add what I have “certified” in my kickstart file. This probably is where we do diverge. I do not configure all end every box, I
    do necessary job with one system class for each of OS releases… –>
    kickstart, but minor tweaks may still be necessary depending on particular tasks on the box.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • This sounds flattering, but no, I’m done with that, no noise from me here
    ;-) so… unless someone wants to pipe that. And improve the statements. And one can put his name under that. As at least what I was saying is so common knowledge IMHO.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • 3. Contribute to the Wiki

    Create a login with a username in the format: FirstnameLastname. For example, if your name is John Doe, the username to be created would be JohnDoe. Other variations, such as johndoe, John Doe, John_Doe, John, johnny123numbers, Mister Doe, JustSomeEditor etc. will not be accepted.

    That is a bad beginning. They don’t want talent just complete subservience. Since when has a user name been more important that the donation of learning, advice, guidance etc ?

    ‘AlwaysLearning’, ‘alwayslearning’ and ‘MrLearning’ makes me ineligible to post a CentOS wiki page. Far better to post on one of my sites than within the restrictive CentOS environment.

    Seen ‘CentOS Pulse’ ?

    “The CentOS Pulse Newsletter is an important tool to communicate within the community. It is run by the community to collect interesting bits from the wiki, mailinglist, fora, SIGs and other sources, and put them into the spotlight.”

    First edition = 2009-06-02
    Last edition = 2010-06-09

    Post the URL of your page.

    I like the idea of a ‘CentOS Learning’ mailing list, as previously described.

  • Nothing wrong with letting “an expert” preconfigure the system and then, after installation, the SysAdmin checking to ensure all the settings satisfy the SysAdmin’s requirements.

  • Wouldn’t that be like having the OS installer require strict passwords, and then have the sysadmin install a less-secure password on test systems after the system is loaded?

  • I’d just rather see them applying their expertise to actually making the code resist brute-force password attacks instead of stopping the install until I pick a password that I’ll have to write down because they think it will take longer for the brute-force attack to succeed against their weak code.

  • That type of reaction dissuades people from contributing to the List.

    Why don’t you personally endorse the creation of a ‘CentOS Learning’
    mailing list to complement the other CentOS Lists ?

  • Impressive “Any time we aren’t inclusive, we lose.” but first it is necessary to have that sort of philosophy as a fundamental principle of CentOS.

    How about some support, on this list, for the creation of a CentOS
    Learning mailing list ?

  • The installer has MANY MANY defaults that are decided to produce a good starting point. Setting a root password that meets an extremely low bar in terms of security was one of those decisions. Honestly, of all the faults and foibles in the Red Hat/CentOS installer, I’m amazed that someone is complaining about that. “Oh No! They released a product that’s *incrementally* more secure than before! Heavens Above! (faints)”

    If you honestly are so unable to remember a password for longer than
    20 minutes, then I suggest using a kickstart to set the root password with a crypted hash. Or have a %post script replace whatever you typed in the password prompt with your insecure password.

    This is one of those decisions many software products have to make:
    Weighing the general security gained by requiring somewhat more secure passwords against the inconvenience of having to remember a somewhat more secure password. Since it’s possible to get around the requirement in multiple ways, it makes sense to lean toward the more secure option. Make it inconvenient to be less secure.

  • Very sensible comment. I absolutely agree. Why do the Fedora Bunch think poncing-around with password lengths and composition is more important than extremely strong external security ?

    There should be a basic defence that when the password is wrong ‘n’
    occasions the IP address is blocked automatically and permanently unless it is specifically allowed in IP Tables. If specifically allowed in IP
    Tables, there should be a predetermined wait time before another attempt can be made.

    Simple ! So why does Fedora prefer allowing the hackers unlimited opportunities to brute-force passwords ?

  • The people who are good at this will make the attempts from many different IPs – and sometimes cycle through a dictionary of different login names too.

  • Also, it isn’t up to the *installer* to set up a system that resists brute-force password attacks. That’s a job for the default configuration files in OpenSSH, GDM, KDM, and any other software product that reads the password database. All the installer can do is read in the plain-text password, check to make sure it passes a minimum policy, then crypt it and put it in the shadow file.

    There are certainly things that could change, like having the pam configuration have pam_faillock on by default. But I tend to think that having brute-force resistance *AND* slightly better password security should be the goal, not one to the exclusion of the other.

  • If ‘n’ is low, perhaps ‘2’, then brute forcing will become more protracted.

    An addition to my proposal, is allocate all sensitive users to a special group and limit the membership of that group to a maximum of, for example, 3 wrong password attempts within a SysAdmin chosen time interval.


  • Good points.

    Consider a user who installs RHEL with a poor root password and reboots while connected to the internet. At that point they are potentially vulnerable. How long will it take for them to get around to improving the password? Probably a long time, unless they are security conscious, in which case they probably would have opted for a strong password from the start.

    Not allowing root SSH access immediately after an install is a much bigger imposition. You would have to insist that there was a second user on the system with a strong password. I think that is a good idea too, by the way.

    Requiring a strong root password really is a small imposition, unless you are doing a lot of manual installs and in which case you should look into automation.

  • Give us the tools to do the job !

    My amalgamated idea is:-

    (1) When external access gets a password wrong ‘n’ occasions, as determined by the SysAdmin, the external IP address is automatically permanently blocked unless that IP is included in a IP Tables ‘allow’

    (2) If specifically allowed in IP Tables, that IP be blocked for ‘m’
    minutes, as determined by the SysAdmin, before another attempt can be made.

    (3) All sensitive users be added to a special group. Limit the membership of that group to a collective maximum of ‘n’ SysAdmin chosen wrong password attempts within a time interval of ‘t’ chosen by the SysAdmin.

    Baffled why it has never been done but then I’m Always Learning.

  • We do.

    Kickstart never really met our needs, and all these now-common CM systems came out way after we had shell-scripted our post-install setup adequately. To go back and rebuild everything in Puppet or similar would be a pointless waste of time.

    Red Hat should do that in EL8, too. Defense in depth.

    Not in our scheme. We set our NICs to come up on boot because we need that in order to pull all the post-installation configuration files, packages, resource files, etc. over from the file server. We also do a “yum update” pass early in the setup process to close any security holes that have opened up since the last EL point release was cut.

    We don’t assign a per-system unique password until the system is almost completely set up and ready to deploy. This step is part of our automatic registration of the new box with our dev ops system, so we can use the new hardened login credentials to get back into the box.

    Until that point, we need to have a password that’s easily type-able, so we use something short and weak. After that point, we’re using an automatic login scheme based on huge passwords and keys.

    Not that I’m suddenly crying about this EL8 change. We’ll just switch from our current pitiful temporary password to something that barely passes the new restrictions. No big deal.

    If you check the “make this user an admin” box in EL7 on the screen that creates the non-root user, it gets added to the wheel group, which *finally* in EL7 allows it to use sudo out of the box. Therefore, a weak non-root admin user password is as good as a weak root password.

    So, your choice is to either not use this feature, or take the new EL8 password rules as the improvement they are intended to be.

    Of course. SSH has rate-limiting built in, and I believe PAM has some that stacks with it, but if the password is too weak, you can still brute-force it despite that.

    I don’t think so.

    Defaults matter. An installer that lets you use weak passwords *guarantees* that people will use weak passwords, and never change them.

    A better airport analogy is the requirement to fasten seatbelts on takeoff and landing. This addresses an actual risk with an inexpensive and low-hassle fix: incidents almost never turn into crashes when the pilot has a lot of altitude to play with.

    I’m not so sure about that.

    While it is true that it is now possible to generate arbitrary 8-character random password rainbow tables without spending ridiculous sums of money, that does not mean you can use the same technology to brute-force a Linux box’s password.

    To do that, you’d have to have the contents of /etc/shadow, which means you’re already root. Game over.

    If the only attack vector is over a rate-limited remote connection, it will take you to the heat death of the universe to brute-force an 8-character password.

    The place you don’t want to use an 8-character password today is on a web site with poor security. Such a site probably isn’t salting passwords even if they hare hashing them, and pulling the credential table probably doesn’t require root privileges. It’s quite a different threat model from the one the Linux login system addresses.

  • Scott Robbins wrote:

    I don’t follow your meaning. Do you think yraM is a palindrome?

    Merriam-Webster (online)
    a word, verse, or sentence (as “Able was I ere I saw Elba”)
    or a number (as 1881) that reads the same backward or forward

    I can’t believe many people use palindromes as passwords.

    Timothy Murphy
    gayleard /at/ School of Mathematics, Trinity College, Dublin

  • Ah, your original sentence was originally quite clear, but I managed to misunderstand it, thinking you meant a word that is the same backwards and forwards, as opposed to what you clearly defined. Sorry. I guess my mind filled in the spaces or something.

  • Yes single character. Writing and testing usually 7 days weekly. Turn off everything when not in use including test machines.

    No connection to the Internet.

  • Sorry. Must have misunderstood your earlier comments.

    Sounds like a fairly specialized work-flow. You might want to consider using an updates.img that removes the password strength requirements (see The anaconda installer is fairly straight forward Python code. I haven’t got a copy on me at the moment, but at a guess, all you need to do is track down the relevant lines and comment them out.

    Hope this helps.


  • I had a friend, now deceased, who worked as an RCA colour TV
    technician when he was very young. In the 1950s he would be sent to the homes of people having trouble adjusting the colour settings on their new RCA’s. That was system administration then. Who needs them now?

    We are dinosaurs. People do not hate us. They just do not understand why we are still around.

    Other than lifting the display into a comfortable position for viewing the latest MacBooks cannot even be physically opened for servicing (by a user) as far as I can discover. An iPhone is a sealed unit. Both devices are orders of magnitude more powerful computers than the i486
    I first installed RH on. The point Les makes is entirely correct. The systems we install should not require the degree of slavish attention to arcane details that is necessary to make them both useful and safe to use.

    That said, the original issue remains, making manual configuration slightly more cumbersome than it already is. That this is done solely in order to make a claim that it somehow improves security is, in my opinion, self-defeating. It is certainly a deceit. Whether it is self-delusion or overt pretence I have no idea.

    One might question why *nix distributions insist on providing a known point of attack to begin with. Why does user 0 have to be called root? Why not beatlebailey, cinnamon or pasdecharge? If brute forcing passwords is the problem then why not make it ever more difficult by forcing crackers to guess what the superuser name is to begin with?

    Oh, I know. Too much software exists that presumes that the superuser name is root. Evidently adherence to that convention is valued more highly than providing security. God forbid that one simply check for user 0.

    I seldom use root other than for peer-to-peer rsync via password-less login. Consequently I do not really care whether Anaconda forces me to use 32 character Base64 encoded passwords for root or none at all. I
    just cannot bear to stand by and read the BS about how anything of that nature improves security. It is just self-deception. Twenty years ago it might have had some validity, although I doubt it. Things that are hard to remember tend to get written down. Things that are written down tend to be read by eyes other than those that were intended.

    The whole matter of attending to the risk of brute force password discovery rather misses the point. Amateurs hack systems, professionals hack people. No matter how resistant your password is to brute force discovery, it only takes one careless mistake to have it revealed by an incautious or suitably deceived sysadmin. Look up
    ‘Robin Sage’ and the follow on study ‘Emily Williams’ and then ask yourself: How does a strong password on the root account deal with that?

    I really wonder sometimes if the software development people that write so much about security ‘best-practice’ have much of a clue about how penetrations are actually carried out. For example, how many of you have ever plugged a USB key into one of your hosts? If you have then you have permanently compromised the security of that system and nothing, short of pulling the entire USB controller, can ever undo it;
    and not even then I suspect. You may not, probably have not (yet), have been infected, but then you will never know for sure whether you have or not.

    There are so many computer control systems that are embedded in the devices we call computers that the attack surface is incomprehensibly large. And most of these embedded systems are completely open to exploitation; at the fabrication level. The Internet is not even the preferred vector. Have you ever used a USB charging station in an airport for your laptop, tablet or phone? Too bad. Have you ever plugged a personal device into one of your hosts at work via USB or Thunderbolt (not likely for the latter I admit)? Oh well. At least you can increase the strength of your root password.

    Is your home or business network device provided to you by your provider? Has it been changed (upgraded) recently without your request (or even with it)? I have to SSH tunnel all of my traffic on my home network now because traffic through my (recently upgraded)
    xxxxxx provided yyyyy router phones home to yyyyy; and I cannot stop it short of jail-breaking, which is in violation of my terms of service (AND I have to pay rent for this device). This is not paranoia, this is observed activity. (Sorry about the xxxxx yyyyy stuff, but on consideration I would rather not run the risk of being harassed by either or both of the two major corporations involved.)

    Sometimes I just cannot bear to think about this stuff anymore.

  • That is more or less what OS X does. User 0 still exists, and it’s labelled as “root”, but there is no way (unless the owner goes way out of his way) to actually log in as root. The first account created is given full sudo access, and can choose to grant sudo to subsequently created users. (Users with sudo can still get a root shell, but that’s not the same as logging in as root.)

    I thought Ubuntu did this as well, but I haven’t installed Ubuntu for quite a while. Anyone know?


  • Not exact analogy. But I know what you are leading to. Once my department decides they will not need me as they will get what is necessary done by faceless big corporation shipping unified services, then I’m out of my job, and will go slaving for that corporation to do what I’m told to do how I’m told to do (which has to yield unified standard product allegedly good). We are not going to break machines and conveyors resisting progress as individual craftsmen of the past did. Even more, few best craftsmen stayed as such even after conveyors were there. But I’m not considering myself such.

    I didn’t say sysadmins. My language was deliberate, I said an existence of sysadmins.

    Yes, these are decisions of incompetent bosses who cover their backsides, and if something bad has happened, they are covered by saying “We did an appropriate thing but still end users defeated our good effort”. And they will get away with it (as they always do) as they will be judged by another bunch of yet also incompetent people.

    I’m a creature of habit. Unix is in agreement with me on that (as I like to flatter myself ;-) So, I endorse “do not change anything unless it is absolutely necessary”. Another way of stressing it is: if you change things people are less likely to do right things until they accommodate to your newly changed environment, so in my judgement, no change here promotes higher average security of computer community.

    [ Of course I mean meaningful things, i.e. do not change root to another name, UID=0 to another number. Staying abreast with password requirements
    (i.e. password should be better that three lowercase letter which might have been sufficient at some point in time, but not anymore) is not fundamental change. It’s tiny increment. Not the fundamental changes I
    meant above ]

    Well, I build Linux boxes with kickstart (after I built manually this kind of box with this release of OS). My root passwords in kickstart are really strong ones. They are being changed however as soon as newly built system is booted (as kickstart content has to be remotely accessible, I don’t care if it is only on “secure” private network. No network medium can be considered secure if more than one – yours – machine is connected to it. Those who disagree… please, consider of taking yet another computer security course).

    That said, I still agree with your feelings about nonsense we are forced to follow. You can not do good to the person who does not wish to do god for himself. And yes, some may follow their own security practice (still I
    for one will take all of A, B and C security measured even if only A meets the goal).

    Yep. I’ve seen sysadmin typing root password in one of his user’s shell
    (and got owned) – I mentioned that in this thread. That, BTW, was nice justification to always do excessive typing and type the whole path to the command beginning from leading slash – when you do sysadmin task at least. There also can be a blunder like changing root password instead of changing user password to trivial temporary password. I’ve seen that done by someone (and mentioned it at some point). I myself was pressed once by very powerful (and knowledgeable!) department member to give him root password for the server. Up to the threat to take it up to the highest boss. I didn’t, but were it the highest boss himself, I can’t make my judgement about outcome even now after over a decade… So, holes vary, yet bad passwords do have their teeny-tiny share IMHO.

    Indeed, you need to think what you are plugging into what. The same as you initiate all connections only in the direction from more trusted machine to less trusted. Never other way around. (Does everybody always follow this rule? No, do not confess ;-)

    Yes, so true. The list goes on. Android devices that have proprietary google code in the kernel. You just reverse engineer it and tell what it does, and even it is evil, it is you who will go to jail for crimes you just admitted above. Or binary proprietary drives, that are in the variety of places – who ever audited these? How about “firmware” – the programs that more sophisticated computer boards run (RAID controllers are the simplest example)?

    Well, luckily I trust most of the board manufacturers (I hate some of BIOSes or EFIs of some, but that is different story). So, the life is not that bad as we have depicted above (hopefully), but at least we realize what we deal with…


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Broadcasters. You still need color balance chops in the TV station or other video production facility; you still need sysadmins in the content delivery facilities, even if they are a bit redundant in the content consumer area.

    Hey, James, go get a cookie, a cup of hot tea, and relax a spell….maybe fire up the old Altix box for a space heater and get nice and toasty warm or something….

    Sysadmins are still around; the areas in which sysadmins are needed and the skills sysadmins need to have are just changing, that’s all. TV
    repairmen still exist; their skillset just is very different today than what it was a few years back. High-end LED/LCD and plasma TV’s are still expensive enough to merit servicing, which most of the time involves module changing, service-remote-driven diagnostic menus, and similar. I still remember needing diddlesticks to do a full convergence job; the equivalent job today involves service menus and diagnostic single-board-computers that talk to the service port.

  • point of attack to begin with. Why does user 0 have to be called root?
    Why not beatlebailey, cinnamon or pasdecharge?
    labelled as “root”, but there is no way (unless the owner goes way out of his way) to actually log in as root. The first account created is given full sudo access, and can choose to grant sudo to subsequently created users.

    Which I consider almost as “security through obscurity” (I said “almost”!)

    I’m neutral to sudo (even though I was taught “the smaller number of SUID/SGID files you have, the better). Yet, I’m considering it less safe to have regular user who can log in with GUI interface, and likely to be doing regular user stuff to have almighty abilities. Yes, I know, I know he has to prepend “sudo”… OK, this seems to be kind of question of taste in the majority opinion.

    quite a while. Anyone know?

    Yes, Debian and its clones have full fledged root account, only with empty password hash (thus making it account for which no password will match). You can enable it by grabbing root shell using sudo, then using command passwd to set password. voila.

    And they are more or less neutral, they do not insist that having disabled root account adds security of the machine (which it doesn’t) – as far as I
    recollect reading their docs.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Note: Ubuntu was first released in 2004. As a matter of fact Ubuntu is one of the clones of Debian which was first released in 1993. Apple OS 10
    (based on opendarwin) – the only one of Mac OSes “root – sudo” talk can be relevant to was first shipped on their machines later than 2002 as I
    recall (wikiedia is really vague on the date MacOS 10 was first shipped, I
    have to rely on my memory). So, I would say, Ubuntu wasn’t copying Apple, they are just a clone of Debian. And Debian is older system than MacOS 10.

    I’m not a historian, so someone probably will correct me, if I’m wrong here.

    Just my $0.02


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • As has been mentioned, fail2ban does this.

    However, the reason you want a password that is not easily bruteforced has nothing to do with this, and all bruteforce attempts cannot be blocked by this method. Scenario:
    1.) There’s some sort of security vulnerability that allows an intruder to read an arbitrary file. This type of vulnerability (whether it be in php, glibc, bash, apache httpd, or whatever) is not rare.
    2.) Attacker uses said vulnerability to exfiltrate /etc/shadow.
    3.) Attacker uses a large graphics card’s GPU power, harnessed with CUDA
    or similar, to run millions of bruteforce attempts per second on the exfiltrated /etc/shadow, on their computer (not yours).
    4.) After a few hours, attacker has your password (or at least a password that hashes to the same value as your password), after connecting to your system only once.

    Now, there are the slow bruteforcers running out there, but those are not the droids this change is looking for. By being ‘encouraged’ to have a difficult to bruteforce password from the very first, you have better security even when the attacker exfiltrates /etc/shadow or other password hash table (I say ‘when’ and not ‘if’ here). And the bar for what qualifies as a secure password (from the point of view that the attacker has your hashed password in hand and is bruteforcing on their equipment) is continually rising as compute power increases.

  • Oh, and the program to do this can be found very easily. It’s called
    ‘John the Ripper’ and has GPU support available:

    Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability of the type that allows arbitrary remote code execution or arbitrary file access. Once the attacker has your /etc/shadow, there is absolutely nothing you can do to keep said attacker from cracking your passwords at full speed. Well, nothing except the password strength itself.

  • [SNIP]

    The behaviour you describe is to be found on Ubuntu, but not Debian. The Debian installer prompts for a root password, whereas the Ubuntu installer does not. The ‘sudo’ package is optional (in APT terminology)
    in the case of Debian.

  • It depends on what you mean by “shipped.”

    The first OS X product released into the market was OS X Server 1.0, in March 1999:

    It was basically OPENSTEP with a Mac OS 8 like skin on top. It didn’t even include Finder, because the first usable version of the Carbon API wouldn’t be completed for another two years.

    About a year and a half later, in September 2000, Apple shipped the OS X Public Beta. This was the public’s first look at the new Quartz/Aqua interface.

    This wasn’t a “beta” in the sense of “This isn’t released yet.” You paid for the disc and Apple shipped it to you. It was more like “We know this is still pretty broken, but we’ve ben promising a new OS since 1997, so if you want to see what we’ve been spending the last 4 years working on, we’ll sell you a copy cheap.”

    Apple shipped Mac OS X 1.0 in March 2001:

    So, there you have have it, a 2-year span during which OS X could be said to be commercially available.

    OS X 1.0 did include sudo. I don’t know if root was actually disabled by default at that point, though.

    I haven’t been able to find out if prior versions of the OS — including OPENSTEP and NeXTSTEP — also included it. I couldn’t even find old manual PDFs or even a man page archive.

    Nope. Though sudo has been in the Debian package repo since at least Debian 3 (2002), the base install has never included sudo. Debian’s sudo package didn’t install with a useful default configuration until Debian 7; you had to manually configure it in Debian 6 and earlier before you could actually use it.

    Needless to say, the root account is never disabled by default on Debian, as it is on OS X and Ubuntu.

    I’ve written up the full details of the non-universality of sudo here:

    Bottom line, Ubuntu *did* copy Apple in this respect, as they have so many times before. (Upstart, Unity, etc.)

  • Thanks for your well-explained concerns. You make good sense.

    Just counted the characters in one of my root passwords. It uses uppercase, lowercase, symbols, numbers and is a mere 25 characters long. Another one is, I think, about 32 characters long.

    Plain FTP is banned. SSH is shifted away to an obscure port and permitted only for 3 predetermined IP addresses. Web hackers are automatically banned after the first attempt. Similar defences are employed against spammers and mail hackers.

    I restrict directory and file access to special users with no-logon ability. I upgrade immediately a replacement is announced. I read my chosen selection of logs and self-created reporting programmes from every server.

    IP Tables restricts in and out traffic as much as possible. DROP appears everywhere.

    I’m not paranoid about security but I do not intend to be a passive or a willing victim of hacking etc. I would jail hackers for a minimum of 6

  • Thanks for the future details. My passwords usually contain letters from
    2 or 3 different languages as well with non-letters inserted every 2 or
    3 characters.

  • This is what I was getting at with my half-joking definition of “technology” in the prior “please stop changing things on us, Red Hat” thread. TVs aren’t technology any more, by that definition: they’re appliances.

    (This Smart TV movement is turning them *back* into “technology,” though. Sigh.)


    I do not believe general purpose computers will ever become anything other than “technology.”

    What will happen instead is that pieces of the current computing world will continue to be sliced off and turned into appliances and tools. My toaster has a microcontroller in it, but it’s still an appliance, not a funnily-shaped computer.

    I think Ubuntu and OS X have beaten that nonsense out of the majority of software by now.

    On Internet-facing CentOS systems I personally manage, I follow Ubuntu and OS X in this regard: disable root logins via SSH, and set up sudo. I usually don’t go so far as to disable the root account, but I do give it a stupidly-long purely random password.

    You’re really going to have a hard time remembering an 8-character password that doesn’t violate the pwquality rules?

    This change is merely enforcing security minima we established about 20 years ago.

    Yes. This is why Bruce Schneier wrote only one book on cryptography, then instead of updating it, he wrote a whole bunch of books on what we might call the peopleware problems.

    While these are good things to keep in mind, none of this is a good argument for allowing truly weak passwords.

    Just because people are the weak point in most security systems doesn’t mean we should give up and allow passwords that can be guessed in a few months at a throttled rate of 5 guesses per minute.

    We need to fix *both* problems.

    If you are referring to BadUSB, you’re overblowing the problem. All BadUSB was is a proof of concept showing that *some* USB devices are reprogrammable in a way that allows them to mimic other types of devices.

    In that sense, a USB memory stick is no more dangerous than a USB keyboard. Both could contain a keylogger, or other things.

    So, buy from trusted suppliers, and don’t stick USB keys you find in the parking lot into any system you care about:

    Fine, don’t. :)

    Let those of us who *do* want to think about it work out how to deal with all of it, and trust that we’re not ignorant of the wider scope of things.

  • Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don’t need to crack your passwords now. You’re already boned.

  • There can be scenario that someone has /etc/shadow due to admin’s stupidity, yet doesn’t have root access. Like: NFS exported / without root_squash option, then everybody having root on different box can mount and have your /etc/shadow.

    But in general, I’m with you. And incident like above is really major incident after which full investigation of all what happened on the box, change of all password (and other thing that too should be considered compromised like keys, certs…) and rebuild of box are mandatory.

    In any case, I agree that whoever let password hashes get exposed… is doomed.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Not exactly.

    There have been remotely exploitable vulnerabilities where an arbitrary file could be read (not written), but otherwise root access wasn’t given by the exploit; that is, no shellcode per se. If you can somehow (buffer overflow shellcode or something similar) get, say, httpd to return a copy of /etc/shadow in a GET request, well, you don’t have root, but you do have the hashed passwords. It doesn’t take an interactive root session, and may not even leave a trace of the activity depending upon the particular bug being exploited.

    Now, I have seen this happen, on a system in the wild, where the very first thing the attacker did was grab a copy of /etc/shadow, even with an interactive reverse shell and root access being had. So even when you recover your system from the compromise you have the risk of all those passwords being known, and unfortunately people have a habit of using the same password on more than one system.

    Further, lists of usernames and passwords have market value.

  • CVEs, please?

    I’m aware of vulnerabilities that allow a remote read of arbitrary files that are readable by the exploited process’s user, but for such an exploit to work on /etc/shadow, the process has to be running as root.

    Most such vulns are against Apache, PHP, etc, which do not run as root.

    One of the biggest reasons for the mass exodus from Sendmail to qmail/exim/postfix/etc was to get away from a monolithic program that had to run as root to do its work.

    httpd doesn’t have permission to read /etc/shadow, two ways. First, it’s not running as root, and second, you’re running SELinux, *RIGHT*? The default configuration of SELinux on CentOS won’t let httpd read *anything* outside its normal service directories.

    But of course the same people fighting this move to more secure password minima are the same ones that turn off SELinux.

    Of course. But that’s a different thing than we were discussing.

  • I just had a peek at the anaconda source for Fedora 21. Apparently you can waive the password strength tests (and the non-ASCII tests) by simply clicking “Done” twice.

    def _checkPasswordASCII(self, inputcheck):
    “””Set an error message if the password contains non-ASCII characters.

    Like the password strength check, this check can be bypassed by
    pressing Done twice.

    Kahlil (Kal) Hodgson GPG: C9A02289
    Head of Technology (m) +61 (0) 4 2573 0382
    DealMax Pty Ltd

    Suite 1416
    401 Docklands Drive Docklands VIC 3008 Australia

    “All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use a hammer.” — IBM maintenance manual, 1925

  • Those are common. Combine them with anything called a ‘local privilege escalation’ vulnerability and you’ve got a remote root exploit. And people will know how to combine them.

    Except that sendmail was fixed. And when the milter interface was added it became even less monolithic.

    Not exactly – it just becomes a question of whether the complexity requirements imposed by the installer are really worth much against the pre-hashed lists that would be used to match up the shadow contents.

    Les Mikesell

  • Rainbow tables don’t help against salted hashes. Rainbow tables are for attacking *un*salted hashes, like NTLM used.

    When the hashes are properly salted, the only option is brute force. All having /etc/shadow does for you is let you make billions of guesses per second instead of 5 guesses per minute, as you get with proper throttling on remote login avenues.

  • On C5 the default appears to be:-

    -rw-r–r– 1 root root 1220 Jan 31 03:04 shadow

    On C6, the default is:-

    ———- 1 root root 854 Mar 13 2014 shadow


    Paul. England, EU. Je suis Charlie.

  • Nope:

    # rpm -q –dump setup|grep shadow
    /etc/gshadow 0 1329943062 d41d8cd98f00b204e9800998ecf8427e 0100400 root root 1 0 0 X
    /etc/shadow 0 1329943062 d41d8cd98f00b204e9800998ecf8427e 0100400 root root 1 0 0 X

    This says it should be mode 400, as it is here on both of the local EL5 boxes I checked.

    You have a serious security hole there, Always.

  • indeed.

    $ cat /etc/redhat-release && ls -l /etc/shadow CentOS release 5.11 (Final)
    -r——– 1 root root 4739 Sep 24 10:54 /etc/shadow

  • Kinda highlights that ‘time’ is important here. Booting into a fresh system and then running updates and hardening your system can take a few minutes. There may be an appreciable difference between having a password that can be cracked in 1 second and one that takes an hour.
    (Yes, infrastructure can help mitigate this risk).

    I’m thinking of someone with limited infrastructure installing a system under time pressure. They might be tempted to use a very weak password initially with the expectation that they would get back to hardening the system later. If they are regularly under time pressure, that may never actually happen, or may be delayed for hours/days. An 8 character password might just nudge the probabilities in your favour and protect against a drive by attack.

    Does that sound like a reasonable case to protect against?

  • Not quite. An LPE can only be used against your system by logged-in users.

    To make a blended attack that can read /etc/shadow from an LPE, you need either SSH access or a remote shell vuln, not an arbitrary file read vuln. Holes that expose an unintended remote shell are quite a bit rarer than ones that allow a service like Apache to send you any file their non-root account has permission to read.

    It’s a bit like calling lightning to find a system where both types of vulnerabilities are available at the same time.

  • Yes, which is why a properly-designed remote credential checking system throttles login attempts: to buy time.

    Safes and vaults aren’t rated “secure” or “insecure,” they’re rated in terms of minutes. This one here is a 5 minute safe, and that one over there is a 15 minute safe. You buy the one that gives you the time you need to react appropriately to an attack.

    That’s exactly what this change does.

    This calculator will help you to explore the problem:

    Put in something like “Abc123@#” to turn on all the green lights to see the effect of a password that will pass the new rules.

    SSH as shipped on CentOS doesn’t allow 1,000 guesses per second, as this calculator assumes, so we actually have a few orders of magnitude more security. Not that it matters, given that it reports that my example password would take 2.13 thousand centuries to crack.

  • Hmm, just thought of a counterattack:

    If CentOS’s SSH currently allows 10 guesses per minute *per IP*, all you need to do to get 1,000 guesses per second is to rent time on a 6,000 machine botnet.

  • Rent ? That costs money. Just crack open some Windoze machines and do it for free. That is what many hackers do.

    Is this safe enough ?


    Online Attack Scenario: (Assuming one thousand guesses per second) 7.26
    hundred million trillion trillion trillion centuries

    Offline Fast Attack Scenario: (Assuming one hundred billion guesses per second) 7.26 trillion trillion trillion centuries

    Massive Cracking Array Scenario: (Assuming one hundred trillion guesses per second) 7.26 billion trillion trillion centuries

    They’ve obviously got slow processors.


    Paul. England, EU. Je suis Charlie.

  • While this discussion has been very interesting, I would like to encourage participants to be very careful about disclosing the specifics their own security efforts. While is good to discuss the pros and cons of strategies, disclosing the details of the exact strategies that you use, no matter how good they are, is a bad idea. This is typically hard information for an attacker to acquire and they would run the risk of generating too much noise if they were to try to acquire it. A somewhat subtle trap is to disclose information about time, e.g., when you last changed a password on a system.

  • Acquiring your own botnet requires time and effort. Renting someone else’s botnet trades one resource for another.

    Nothing is free. Just as with my analogy with safes, we’re not talking about absolute security. We just need to make an attack *costly enough* that it will never succeed, if we do our part. (Like not saying chmod 644 /etc/shadow !!)

  • Thanks for the heads up. At least we know it can be easily reinstate it via an updates.img — for those testing installers in sandboxed environments.

  • I looked on a DVD backup of the 2010 standard install of a VPS (without looking again I think it was C5.3).

    Spreading good ideas and techniques (see my “CentOS Learning” mailing list suggestion) could encourage newcomers to implement good security as soon as they arrive on Linux. I found switching to Linux without help was a steep learning curve but, as usual, I survived. I’m still Learning.


    Paul. England, EU. Je suis Charlie.

  • Or any running program – like a web server.

    No, you exploit the server application hole to tell you about the kernel vulnerability. The last one I saw in the wild involved the symlink race in the kernel around CentOS 5.2 or .3 and a struts java library bug. But there are people who know what combinations of vulnerabilities to try.

    Les Mikesell

  • That’s not what LPE means. “L” = “local”, meaning you are logged-in interactively to the server, or have the ability to execute arbitrary commands remotely, which comes to the same thing.

    The only way Apache can be used in conjunction with an LPE to provide root access is via something like Shellshock.

    I’m not saying LPEs, remote shell attacks, and arbitrary command execution vulnerabilities do not exist. I’m pointing out that each of these classes of vulnerabilities are rare on their own, and rare times rare equals scarce.

    There’s no such thing as absolute security. There is only better and worse; somewhere along that continuum is a point labeled “sufficient.” Policies like the one we’re arguing over merely attempt to set a sane minimum level.

  • The instance I saw used a java web server, but server bugs that allow allow execution of arbitrary commands have been fairly numerous –
    shellshock might have worked too. And that’s all you need to turn what you thought was a local vulnerability into a remote one.

    Les Mikesell

  • I think it’s basically six of one, half-dozen of the other. Is a user any more or less likely to screw up his box if he has to log in as root or has to use sudo? I really don’t know. OTOH, forcing sudo does have one advantage, in that every sudo command is logged. (If you do sudo su you lose that.)

    I believe that on recent OS Xs this method no longer works (it used to).

    As to the original topic (heh), isn’t it a bit counterproductive to complain about changes in Fedora or RHEL on this list? Those distributions are separate entities with their own decision making processes. If you want to complain about Fedora, go to their list
    (which IIRC the OP pointed people to). If you want to complain about RHEL, buy a RedHat suport contract. It seems to me that the only legitimate complaints one could make about CentOS would be if they went out of their way to make CentOS different from RHEL in a very suboptimal way. Do you really have any justification for complaining if CentOS
    enforces the same password requirements on install as RHEL?


  • After all this discussion about “is this enough for good security or should we add something else” the last not requiring tremendously larger effort, I’m left with the following feeling. I’m a “relict” left from long time ago when security was considered paramount, when if something can be done it had to be done, no matter that the same is allegedly covered by something else already in place. We always considered the word “paranoia”
    is in sysadmin’s job description (I still do, yet I didn’t check IT job descriptions lately, – maybe I should take a look; there seem to be many
    “Windows” brew people up on the top of IT ladder these days). I feel like there is brave new world of admins who feel it right to have “iPad-like”
    everything, i.e. boxes cooked up and sealed by vendor, and you have no way even to look inside, not to say re-shape interior to your understanding
    [of security or anything else]. Am I the only one?

    Not that this my comment meant as contradiction to any particular post
    (this post I’m replying to included). It is just the existence (and length) of this discussion (whether one should, or shouldn’t, or anything)
    makes me think that what I was trained about security is not accepted by many these days. Or maybe I simply got tired following it instead of spending more time doing my own sysadmin’s job ??

    Good luck, everyone. Stay safe and keep your boxes secure!


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Those crackers who build these botnets are the ones who rent out botnet time to people who just was to get the work done. There is a large market in botnet time.

    Yes, it is.

  • CVE-2006-3392 for one. As this one was against Webmin, well, webmin by nature has to have root access. Yeah, webmin should not be configured to be accessible from the internet at large, but that’s not the point.
    Yes, it is an old one, but there are I’m sure other vulnerabilities that have either not been found or not been published.

    And then, a long time ago, in an OS far far away, there was CVE-2000-0915 (FreeBSD 4.1.1 Finger Arbitrary Remote File Access) where the advisory text description included the following wording:
    “The finger daemon running on the remote host will reveal the contents of arbitrary files when given a command similar to the following :

    finger /etc/passwd@target

    Which will return the contents of /etc/passwd.”

  • I second that.


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • I know this is joke. Yet (in a slim chance someone out there can follow it with seriousness) I would strongly suggest:

    Don’t do it. Don’t use anything as any sort of password which was ever publicized in any shape. Putting it in a search line of any search engine, or it passing it over to any (but your own) password strength checker has
    (fair in my estimate!) chance of that to be logged, added into the database, etc. I almost which to yell: people use your brain ! ;-)

    I know, I know, everybody is reasonable, it is just I didn’t have my coffee yet…


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • You are conflating two unrelated things. Being shipped with usable defaults has nothing to do with your subsequent ability to change them. Just the need and advisability of such work.

    It’s not that it is wrong – just that if there is one or a few way to do it right, the box might as well come that way or with just those few choices to get a working default instead of requiring individual attention to a million details.

  • On Wed, February 4, 2015 17:16, Lamar Owen wrote:.

    And the arbitrary change made to Anaconda deals with this difficulty how, exactly?

    Look, I am neither for nor against setting arbitrary standards for user-passwords. In fact, his is what I do to generate system passwords:

    cat /proc/sys/kernel/random/entropy_avail

    openssl enc -base64 < << $(head -c 32 /dev/random) | \ sed 's/\(....\)/\1:/g; s/.$//' BuRd:f8qU:yY8M:pbtO:uDlw:D53k:whW+:eJtC:z8Tc:4zlo:hiIK and discard the ‘:’ which I provide simply to make it easier for me to read and type the damn things (once). My belief is that trust in such passwords is totally misplaced. However, if such things makes you feel comfortable (like avoiding crossing paths with a black cat or walking under ladders) then that is your affair and who am I to disagree with your choice. The change to Anaconda is not an issue because of what it is but for how it was done; arbitrarily, without community input, and without consideration of other points of view. That arrogant act was then excused under the rubric of ‘increased security’. It that part which irritates me. My indulgence in raising this issue at all is to highlight the inappropriate responses that the human desire to do ‘something’, ‘anything’, no matter how pointless, so often trump considered reflective contemplation of the problems and what options are available to deal with them. I am tired of reading of so much wasteful nonsense being excused under the general heading of ‘security’. And so I call people out on it now. Prove to me that any increase of cost imposed on me by your decision actually improves my security to a degree that the benefit is measurably greater than the cost. And DO NOT discount my time as having no value. If you cannot prove that then just b*gger *ff. I may have to put up with that crap for want of any viable alternative but, I am not going to nod sagely and pretend that I agree just because currently that is the socially acceptable way of receiving such professions of belief. It is BS. It has always been BS. And it will always be BS. There are no secure methods of public communication. One can only attempt to increase the expense of surveillance to the point where the value of the information received is less than the cost of getting it. If someone values it highly enough then no amount of expense is going to dissuade them and they will have it, eventually. If the cost of surveillance is cheap enough then everything will be surveyed and everyone will have access to your information. But surely, it is the choice of the parties owning the information to decide how much value it has and exactly how much expense is justified in protecting it? Access to computer systems has to considered from the point of view of eventual compromise. Is not if, it is when, you are compromised. The critical considerations are: how will you detect it; how much penetration will result from each potential point of entry before it is detected; and how much effort will it take to recover?

  • Foolish and stupid implicit trust in a third party. Just look at the Windoze world ever since Win95 (first edition of many) materialised. Trust M$ and get a free virus every time !

    I don’t use my Android tablet after I discovered a default setting
    (semi-hidden away) was “Trust Google by automatically sharing all passwords with Google”. I would like to use the tablet but only when there is a major free and entirely open source version of Linux available for it.

    Then there is the BIOS (or similar) with a functioning TCP/IP stack, so I am told. How good is security when a low level backdoor exists ?
    Keeping Uncle Sam and his associates out does not make everyone a dangerous threat to public safety and to national security. Don’t forget about the Chinese switching equipment which some believe could be controlled remotely by the Chinese.

    Paper and pen (or Biro/ball-point) was massively more secure. Are we stupid because we place so much inherent trust in the honesty and integrity of others whilst never having an opportunity to verify their offerings ? Open Source, all the way down to the motherboard, is increasingly important for the efficient and safe functioning of our global society, from traffic lights to hospital live-saving machinery.

    When will CentOS (RH) be able to replace Google on Android tablets ?

    It is not only the “boxes” which must be kept secure. Increasing amounts of data mean security must be increased too and become a normal ‘way of life’.

    In addition to my CentOS Leaning mailing list suggestion, I would like to see a free web based CentOS security questionnaire to ask users security related questions and then present a rating based upon their correct answers. Red Hat people and Fedora people too lurk on here, yet there is a reluctance (probably commercially inspired) not to fully respond to the challenges threatening all of us ‘today’.

  • Yes never ever, not once, let any person or any search engine etc. know too much about your specific security arrangements. Generalise with principles but always withhold the precise specifics.

    The nasty people out there are trying to steal your data and wreck your systems. They have no scruples. There is a real cyber war going-on and your systems are their targets.

    Your logic is amazingly good for a coffee drinker.

  • I wouldn’t go there unless you want to compare against, say Red Hat 4
    (original, not RHEL) of the same era where virtually every service had remote exploits – and we are still finding them. Or unless you have some sort of proof that a current Windows 2012 server is less secure or stable than a Linux distro.

    Let’s start with why your /etc/shadow has read access. That’s one of the things that was right out of the box. What changed it and why?

  • Ah. Sorry, NO.

    First, we are not talking about a more secure password minima. We are discussing an arbitrary change made to an installer program that adversely impacts usability and that only has a tenuous connection to security on a production system. A change which assumes that people installing RHEL systems lack the competence to alter system account passwords subsequent to installation.

    Second, while I have serious concerns with the delusions respecting security that this fascination with ‘strong’ passwords evidences I do not turn off SELinux on any of my production servers. Excepting one which to date I have been unable to get to run the critical
    (third-party) application it hosts with SELinux switched on (short of a custom module which effectively gives http access to the whole host anyway). And that server is hardened against Internet access via other means and only runs this one application.

    You need to paint with a finer brush I think.

  • Not every ‘home’ or business user uses, or can afford to purchase, Windoze 2012 Server. Besides that is far too large for end-users. Conversely everyone can use and afford (because it is free) to install Linux as a server, as a end-user (non-server) or as a mixture of the two. The Linux flexibility is one of its many strong points.

    Yes that is what I would like to know. Can’t tell. That disk was wiped, partitioned differently and reformatted. But it remains a puzzle I am unlikely to forget for a long time. I carried-out a check on every machine and was happy to see ———- .

  • No, I wasn’t born here though I live here, so I don’t take to my heart any jokes about people living in one of the colonies you lost ;-) Just stealing it from some movie I like. Still didn’t have chance for my morning coffee yet (which I deserve: I was working hard all morning). Don’t take me too seriously too, just get nice cup of tea (or wait till morning for it) ;-)


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • The Feds in which country?

    Do note that now that it has been posted to a public list, while it was safe while unpublished, it would not be safe in the future. I have in my possession a file of passwords from a compromised server here, from several years ago. This was part of one of the slow-bruteforcer networks out there, and is one reason we now whitelist only needed outbound connections on port 22 and block all others on our two internet connections.

    Incidentally, this particular slow bruteforcer didn’t need root to operate. The password list has about 65,000 passwords in it, some of which would have been considered strong passwords. Well, until they made the list. Your password is just about guaranteed to be on future lists…..

    However, another password with similar characteristics would be fine.
    You just never want to use it on more than one server to be safe…..

  • Yes. Using my brother’s joke, whole life is struggle: before lunch with hunger, after lunch with sleepiness…


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • I thought you were Russian from the way you sometimes phrase your sentences. My mixed ancestry is European. I didn’t loose anything, at least half of me didn’t. Although I do like a cup of tasty tea, I have never tried the Boston Vintage.

    I favour the European Union making open-source computer operating systems the preferred Public Sector choice. The massive state-funded M$
    domination, and effective monopoly of new desktops and laptops, stifles innovation and competition. (‘State’ as in sovereign state)

    Its time a free CentOS DVD was given away by retailers selling consumer desktops and laptops (including netbooks, notebooks etc.). Forcing consumers to buy M$ at extra cost is wrong.

  • The USA for a start. The USA’s law enforcement is never slow at working with foreign countries law enforcement to secure the arrest of offenders upsetting the USA – sometimes having them extradited to the US of A for trial.

    More effort must be made tracing the hackers. Hacking is routinely accepted too often. If a burglar attempts to break into a bank, does law enforcement forget about it ?

    Have absolutely no intention of using it or anything resembling it. The security risk is too great !

    Port 22 is always blocked, port 21 too, on all machines. Too risky. Having port 22 open will give me sleepless nights.

    Then let them waste their time and energy attempting to crack a non-existent password.

    Agreed. Never ever repeat the same passwords on different machines.

  • It is much more likely that someone has screwed up your system. I think even CentOS 4 had shadow as 400. And what on earth would the point be in having a world-readable shadow file?!? The whole point of having a shadow file is to keep password hashes out of /etc/passwd so that people can’t read it. It would be nonsensical to then make the shadow file readable.


  • Yes, /etc/shadow would have always been readable only by root by default. The interesting question here is whether an intruder did it, clumsily leaving evidence behind, or whether it is just a local change from following some bad advice about things that need to be changed – or running some script to make those changes. The latter seems more likely to me.

  • That is why I posted earlier today

    “Yes that is what I would like to know. Can’t tell. That disk was wiped, partitioned differently and reformatted. But it remains a puzzle I am unlikely to forget for a long time.”

  • Be it me, I would consider box compromised. All done on/from that box since probable day it happened compromised as well. If there is no way to establish the day, then since that system originally build. With full blown sweeping up the consequences. Finding really-really-really convincing proof it is not a result of compromise (and yes, fight one’s wishful thinking!).

    But again, it’s your money in your bank (and/or whatever else could get into jeopardy).


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • You aren’t being paranoid enough. If it happened as a result of following some instructions or running a script, it’s not just the box that is compromised, it is everything you think you know. On the other hand it could have just been an accidental typo.

  • Logically ?

    1. to change the permissions on shadow from -rw-x—— or from
    ———- to -rw-r–r– requires root permissions ?

    2. if so, then what is the advantage of changing those permissions when the entity possessing root authority can already read shadow – that entity requires neither group nor user permissions to read shadow.

  • there’s a very useful tool built into CentOS’s ‘expect’ package…

    $ mkpasswd -l 15 -d 3 -C 5

    $ mkpasswd -l 24 -d 3 -C 5

    $ rpm -qf `which mkpasswd`

    but, Dog save someone from having to type said passwords even once and get it correct.

  • Really? My take is to take it as seriously as it can potentially be. It
    _is_ paranoid, and is paranoid enough. Which would constitute pretty good compliment responsible sysadmin can get ;-)

    That’s why I said “avoid wishful thinking”.

    Yes, but “could have been” is one story (then, still variety of important things may be left in jeopardy). Finding the proof that it is accidental typo or stupid script is another. The second one takes much more time and effort in my experience. I figure my teachers deserve their share of credit for teaching me the way I am. Your response to incident that just got discovered may be different. But what, after all it is your money
    (well, _his_ money in this case). As I figure, there are no other users on this box. But imagine there are…


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • No, you are saying don’t trust that box.

    I’m saying don’t trust the source of the advice you were following when this happened.

  • As I said, it’s your money, mister.

    Think of what your users will think about your response to bizarre you have discovered. Sysadmins have their users’ trust a priori. But they have to keep deserving this trust all the time.

    Just my $0.02


    PS I figure I really have to thank my teachers! Including great books I’ve read…

    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • The concept in play here is privilege escalation.

    An exploit may not give you all that root can do, but may be limited to, say, tricking the system to change file permission. From there an attacker could use that and other exploits to escalate privileges.


  • Warren Young wyml at Tue Feb 3 00:32:15 UTC 2015

    Keep in mind the original context isn’t for production computers, it’s testing Fedora. Many testers do dozens of installs per week, some do dozens per day. The password requirement is pretty annoying, I for one haven’t tested it since I worked with the first build that includes the change. Why?

    While ostensibly it’s an 8 character minimum, pwquality is sufficiently capricious that 8 characters is frequently insufficient. I tried about a dozen times and failed, gave up, and went with an ill advised 10 character password that I forgot within 30 minutes after the installation was complete.

    The problem is the decision to stop innovating ways to incentivize irrational users into producing stronger passwords voluntarily, and instead bringing out boxing gloves to make everyone do it by force. It’s inherently adversarial.

    Someone else made an analogy with the anti-immunization camp. The analogy has some fatal flaws, but one of the ways it works is the irrational reaction component. As it turns out if you call these people names, tell them it’s safe, give them all the facts, they just become even more intractable because it’s not even about that. Making it compulsory is likely to do the same thing and worse. The way to do it is to establish incentives. If you want your kid going to public schools of any grade, then immunization is a prerequisite. Of course it’s your choice, ultimately. Good luck with private school. Here too what’s going on is a lack of a mechanism to tie default services with a sufficiently acceptable password. e.g. a checkbox for sshd being enabled is grayed out, not even checkable, so long as the password is crap.

    Or iterate upon the basic concept which is, you get something for something, bring the user along and get them to change their behavior rather than poking them in the eyeball without any respect to the use case.

    Windows, OS X, iOS, Android, have much weaker password enforcement than is currently in Fedora 21 and older (and RHEL 7 and older). There’s no password even required on mobile devices. I can use a 4 digit PIN to get money out of an ATM. Context, use case, and other mitigation mechanisms are relevant. And the debate is whether a stronger password requirement is really worth, e.g. having root remote login enabled by default on Fedora Server. Whereas sshd isn’t enabled on Fedora Workstation.

    Over on Windows and OS X Servers (try not to laugh, stay on topic!), the expectation is you bring over a USB keyboard, or connect with serial or ethernet console. You opt into remote services explicitly.

    I’m the first to fight boneheaded “password security” schemes like a

    Actually I put it in the category of rearranging the deck chairs. It’s a debate about very weak vs weak passwords. And I think this will just cause some people to consider their less crap password to now be fair or strong. If we really want strong passwords, we’re talking in the vicinity of a compulsory 20+ character password (or passphrase rather). No need to tell me how you feel about that, I’m pretty confident I can predict the response.

    It’s a good gripe, I don’t like it either. However at least Apple and Microsoft have direct paths to work around this seeming requirement. I
    don’t know about ChromeBooks, but certainly on my Android (actually cyanogen) phone I don’t have to use a password at all for the phone itself, just services.

    Yes and it’s under discussion to make keys compulsory by default rather than passwords for at least root remote logins. Hard to setup compared to a password. But once that’s done it’s actually easier to use.

    Chris Murphy

  • It seems very likely that, even if the system’s security is not compromised, the sysadmin’s certainly is. Some things are beyond our ability to repair.


  • In the politest manner may I suggest the ability to read and the ability to retain information is important ?

    Somewhere previously in this threat and within the last few days, I

    1. the file permissions were found on a 2010 DVD back-up of a 5.3 ?
    CentOS installation;

    2. all my current systems C5 and C6 have ———- permissions for the shadows (shadow, gshadow and their backups)

    3. the disk drive originally used in 2010 was wiped in 2010 or 2011, repartitioned, reformatted and reused.

    4. I don’t know what happened and despite being concerned and curious I
    am unlikely ever to discover the cause

    Why waste time on this, when CentOS Learning, IP TABLES firewall for beginners will bring substantially greater benefits to everyone ? OK, not for the hackers !

  • Jonathan Billings billings at Tue Feb 3 20:35:44 UTC 2015

    Someone is trying to keep the scope of such faults and foibles on topic, otherwise they’d easily be tempted to get carried away.

    “Oh No! They released a

    I agree it’s incremental, in the realm of turning hours into days, or days into weeks. I think we’re well past 8 character passwords taking centuries to crack by brute force. Therefore I think it’s a distraction, pointlessly incremental for staving off remote login attacks. The common attack vectors on users gets them to reveal their password, no matter its length. Or tricks them into agreeing to escalating process privilege even without a password.

    If you want something meaningful, disabling sshd by default has a more meaningful effect, and it’s more typical (at least in terms of deployment volume) so everyone should be familiar with the idea.

    This is one of those decisions many software products have to make:

    I can set “moon” as the password on OS X, as an admin. Do you think a company, and its users, with such a big target on their backs, haven’t considered the benefit of requiring somewhat more secure passwords? So far they’ve spent quite a lot of development effort (their own and 3rd party developers) on sandboxing functionality and constant policy adjustments over the past few years. If it were worth it, it’d be a lot easier to just say, shift the burden to the user, and make them pick a 10 character password.

    Chris Murphy

  • come on guys, If a cracker changed the perms to 644 he’s probably sensible enough to change it back to 000 after grabbing a copy… this is most likely a BCAK error, let it rest please.

  • [….]

    Both denyhosts and fail2ban can be installed from yum or dnf; is the same then not true for CentOS?? It worked on my wife’s machine. (I’m presently fighting a strike by the box on which I normally run CentOS on my desk in order to be familiar with her OS.) Maybe I have some repo set for it that you don’t??

  • If I can give myself read access to /etc/shadow, then I can grab a copy and try to crack the passwords (including the root password). If I can give myself r/w access, then I can directly change the password and give myself instant access to everything.

  • I guess, this discussion (about security of your system and what affects it) should be ended by the reference to fundamental book on Unix system
    [administration]. One thing I learned: you can not become proficient in any subject just by reading sparse blogs about it. One thing you definitely need: very good understanding of underlying fundamentals. For this reason the most productive would be to think if you have very good general understanding of how Unix (or Unix-like) system works. The easiest is to start reading good book about it, and if you see you are making discoveries, then this is definitely what you are missing, and what you need to study before diving into discussion what is good for security and how it affects that. That would be what I would recommend to myself (which I did way back…). If I were choosing the book to get good start today, I
    would choose:

    UNIX and Linux System Administration Handbook (4th Edition) 2010 by Evi Nemeth and Garth Snyder

    – don’t worry about “outdated…”, remember, you first need fundamentals. It is not as “fundamental” as some of the books of the past I remember, but I’d rather mention it that those really old books.

    I’m sure, someone may suggest better book, maybe even free online book. Note, your advise of book giving fundamental knowledge of Unix or Linux system may be really valuable.

    Just my $0.02


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Brilliant logic about ignoring the publication date.

    I did a Google on

    “UNIX and Linux System Administration Handbook (4th Edition) 2010 by Evi Nemeth and Garth Snyder”

    The third item was a 16.1 MB PDF of 1,344 pages. A quick scan of the PDF
    shows every page appears to be readable. 11 pages devoted to BASH. Information on other interesting topics too.

    Although I have a natural preference for paper books (I became a computer person at a large international book publisher) and I like the ability to annotate text, the PDF is definitely a useful and informative read.

    Thanks Valeri.


  • Thanks Jonathan. John R Pierce also mentioned that it is hosted in Russia. I for one would definitely avoid this source. If I were to set myself a goal to get fundamental book I would wait a bit, as some clever people may recommend something else on this list, then choose what looks most fundamental to you. I would ask John Pierce and Jonathan Billings: what would you, gentlemen, recommend for the one who decided to become really very Unix (or Linux) person – understanding in-depth how the system works?
    Other experts (I know there are many on this list)?

    Thanks. Valeri

    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • +1

    Yes, good people have to feed their families, so their work has to be paid for (by us, customers, through buying good product).

    I would also wait for other advises (maybe someone suggests better book).


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Probably not really a software pirate but an individual (and a keen cyclist) storing some old-ish PDFs on his own web site.

    One I noticed was “Free BSD, 2009” all 857 pages present – in Russian. Another is a 2005 Linux PDF book in Russian.

    No copyright on his photos including long empty roads, sunlight, countryside and an occasional motor vehicle. For example

    of in the countryside

    I really liked and appreciated the filming perspective (position) in the Italian video

    So there is little to fear from the web site of a Russian cyclist who likes Linux. Although I would have preferred him to like CentOS more than Debian.

  • The PDF *itself* is still pirated. It has nothing whatsoever to do with
    “software” piracy.

    I don’t even fully trust docs written by any third party until I can cross-check it against official documentation. So I definitely do not think it’s okay to trust pirated documentation from a Russian site I
    will never be able to know anything about.


  • PDF
    Information on other interesting topics too. violations.

    There is misunderstanding here. My original reference _IS_ ethically available. The paper born copy of the book can be bought, say, on amazon:

    What was bashed in successive posts was pirate copy of the same book hosted somewhere in Russia. Whereas it is strongly advisable to stay away from pirate copy, this fact should not reflect of real book itself. Buying real book is by no means unethical.

    Still, there are many knowledgeable people on the list, they may give different recommendation, which will create some pool of choices. I asked John and Jonathan, I’d like to ask also Les Mikesell and Mr. SilverTip257:
    what would you, gentlemen, recommend? Anybody? (I know there are many experts on the list – larger number than my poor brain can hold ;-)


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Which should not reflect on the book I recommended:

    (Neither should the fact that the one who recommended it – myself – has Russian origin too. I for one hate the fact that copyright – and decency –
    are so much violated on the territory of Russia).

    Still, as I stressed in my original suggestion: to get proficient in anything one has to learn fundamentals, so I would forget about blogs, web posts, and would begin with a really good book. Unless you are already an expert in a sense you know fundamentals (but this question is the one that one can only answer by himself).


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Are you looking for something simpler or more detailed than the obvious starting point?

    It may be good to read other guides to understand what is specific to RHEL/CentOS and what works in general, but there is probably more than you want to know in the official docs.

  • Keith neither of us know whether or not the Russian man obtained his PDF
    copy of the book lawfully. In my book-publishing opinion, the PDF
    appears to have originated from the book’s publisher, so the original source must have been *the* official source. Hence the book, in the PDF
    version, must have been written by the official authors.

    The existence of an alleged unpaid-for copy on a foreign web site can not, in any sense whatsoever, denigrate, diminish nor deprecate the official authors distinguished achievement.

    There are poor people all around the world who enjoy computers including Linux and whom would benefit from learning more about Linux. Some who can read English sufficiently proficiently to benefit from the book’s text, may be too poor to afford the, to them in their country,
    “exorbitant” Western price for an “official” copy. Some publishers recognise this reality and sell in third-world countries at a small fraction of the “Western” price. In those circumstances selling PDFs for an extremely low price may be the source of this particular PDF
    especially as hardbacks and paperbacks could never economically be sold as low as a very low cost “official” PDF copy.

    Depriving people of learning (also known as education) keeps them in political and economic subjugation to the detriment of the Human race.

    Would be nice to gain some support for the CentOS Learning mailing list suggestion :-)

  • I agree with Valeri’s assertion that fundamental knowledge is more important than web post or blog snippets.

    When building a house, it is important the foundations are perfect and solid otherwise – if there are gaps in the structure supporting the building – that building is likely to be unstable. This analogy also applies to computer operating systems.

  • Thank you, Les, for, probably the most relevant starting point.

    As one who is constantly driven to distraction by spelling and grammar errors when reading such an offering, I’d like to know how a member of the CentOS project submits improvements to something in the RedHat documentation. Can you provide guidance in that regard?

  • Please allow me to make sure I am perceiving this correctly, reports of errors found in RedHat documentation are to be reported against the Fedora Documentation product type in the RedHat bugzilla?
    and reports of errors found in Fedora documentation are, also, to be reported against the Fedora Documentation product type in the RedHat bugzilla?

  • I don’t know officially, but I’m making a guess that, since the two documents are clearly related and have the same authors, if you see the same error in the Fedora document and you report it, it will probably get fixed in both. The Fedora document explicitly solicits bug reports, but I don’t see the same in the RedHat one. Worth a shot don’t you think? Maybe submit a small bug report and see what the response is like?

  • Unless the guy who is posting the pirated PDF downloaded it from a shady site that inserts PDF viruses and whatnot. The point is, it’s neither ethical nor safe to use this pirated copy.

    One of the authors, Evi Nemeth, was a really great and interesting person who I’ve heard speak at conferences. She also co-wrote the Linux Administration Handbook, which I read both editions years ago, so I can vouch for their quality. However, as computer books are most likely to do, they are quickly made out of date by the rapid pace of linux development (even Enterprise linuxes like CentOS).

    I learned my trade mostly through doing, watching other people do things, reading lists, and attending conferences, Linux Users Groups and other meetings of Linux admins. I love books, and continue to buy reference books for languages and favorite software tools, but I don’t have any recent Linux books.

  • Officially, no, the “Fedora Documentation” bz product isn’t there for Red Hat guides. If you want to file a bug against a RHEL guide, choose your version of RHEL then look for the guide’s component – these days, they all start with “doc-“, which should make the search easy.

    Unofficially, there’s a nonzero chance that your bug will find a writer that plays in both spaces, or that we’ll be able reassign the bug to the correct component for you. But please, don’t make work for Fedora volunteers when there are people standing by getting paid to handle your bugs :)

  • Thanks for the heads up. Was not aware of the ‘doc-‘ prefix.

    As previously noted, the authors of both documents are the same, and appear to be RedHat employees.

  • Right, that’s the non-zero thing I mentioned. Some Red Hat writers also contribute to Fedora Docs, often on their own time.

  • Right, that’s the non-zero thing I mentioned. Some Red Hat writers also contribute to Fedora Docs, often on their own time.

  • Remember, Adobe Flash BAD, Adobe PDF GOOD.

    Amazing how quickly security fundamentals — like declining to download a file which can contain scripts that run on the local machine from a clearly dodgy site — go out the window when put up against expediency.

  • Yes, expediency. And cost, quite likely (even though it is better than affordable). That really suggests the need to learn fundamentals (I would put in order: Unix or Linux system basics first; system security second).


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • 1. Flash I don’t have or use.

    2. PDFs can be created by *NON-ADOBE* software. PDF’s (well most of them) can be opened by non-Adobe PDF-type software.

    3. The Russian’s web site is that of a devote cyclist. Most of the films on his web site are of cycling or about cycling. Most of the oldish PDF
    files are about Linux and in Russian. I do not consider his site presents a malicious danger to me.

    Warren, it is senseless you wasting your valuable time trying to make me do what you want. The system here just does not work like that – perhaps elsewhere but certainly not here.


    Paul. England, EU. Je suis Charlie.

  • Valeri and Warren,

    My decisions are based on what I know. Those decisions can be called
    “informed decisions”.

    I am not abdicating anything to you two gentlemen.

  • Another bored expert desperate for a modicum of excitement ?

    You have absolutely no prima facie evidence to support your assertion.

    I refer you to my posting dated Mon, 09 Feb 2015 22:10:35 +0000 which includes, inter alia:-

    “Keith neither of us know whether or not the Russian man obtained his PDF copy of the book lawfully. In my book-publishing opinion, the PDF
    appears to have originated from the book’s publisher, so the original source must have been *the* official source. Hence the book, in the PDF
    version, must have been written by the official authors.

    “The existence of an alleged unpaid-for copy on a foreign web site can not, in any sense whatsoever, denigrate, diminish nor deprecate the official authors distinguished achievement.

    “There are poor people all around the world who enjoy computers including Linux and whom would benefit from learning more about Linux. Some who can read English sufficiently proficiently to benefit from the book’s text, may be too poor to afford the, to them in their country,
    “exorbitant” Western price for an “official” copy. Some publishers recognise this reality and sell in third-world countries at a small fraction of the “Western” price. In those circumstances selling PDFs for an extremely low price may be the source of this particular PDF
    especially as hardbacks and paperbacks could never economically be sold as low as a very low cost “official” PDF copy.”

    FACT: Valeri’s recommendation is, in my opinion, a useful source of basic knowledge benefiting CentOS users regardless whether that book in printed on paper or is a virtual or an electronic “book” (i.e. PDF).

    ANOTHER FACT: Linux Programmer’s Reference, Petersen, Osborne McGraw-Hill 1998 – ISBN 0-07-882587-3, which I obtained on 27 October
    2000, is also a good good source of useful information. I’ve started re-reading the 71 pages on BASH. I never knew the first character on the first line could be a space.

  • And SWFs can be generated by non-Adobe software, and JARs can be generated by non-Oracle software. What’s your point? Is it that only Evil Corporations can create software that can be used for evil purposes?

    Are you back on the “F/OSS software is invulnerable” bandwagon already, after being knocked off it a week or two back?

    So what do you do when you get a PDF that *can’t* be opened by your non-Adobe PDF reader? Do you discard it and go find another way to get the content, or do you grumble and fire up acroread?

    I’m a devout cyclist, too, yet you’ve apparently decided I’m an enemy.

    What makes this other guy unimpeachable?

    I could care less that he’s Russian, or a cyclist. What I care is that he’s purposely providing illicit goods. That’s enough for me to distrust what he’s providing.

    This Russian cyclist doesn’t even have to be the source of the evil. Chances are that he didn’t buy this PDF from an official source and offer it directly. It’s far more likely that he’s just another step in the chain back to the original source. Why are you trusting all of them, too?

    Make you? How am I going to accomplish that? I have no power over you.

    I just thought that, since you were Always Learning, you’d want someone to tell you when they saw you doing something that could compromise your security.

  • Just to make it clear: I recommended the book itself without pointing to any source of it, and when pirate copy was mentioned by somebody else, I
    had to say I do not recommend that source and would recommend to buy the book on amazon.

    The guy who put document copyrighted to somebody else is either stupid or ignorant (and I don’t care if he is Russian, Bulgarian, Chinese, or USA
    person, or…). Ignorance in this place is akin full disregard of another person’s hard work and rights (Book brilliant authors’ and copyright holders’). I doubt we can educate that Russian guy. Unless someone who feels good towards him can find way to contact him and explain everything… Not I definitely ;-)


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • Warren, I have never declared you to be an “enemy”. I am an all weather cyclist who used take his bike as luggage on aircraft.

    Then go and complain to the USA’s FBI on +1.202-324 3000. It is not a CentOS issue !

    Please don’t waste your time moaning about something which is not related to CentOS.

    I never stated I was stupid. Being in the world’s top 2% of brainy people neither deprives me of decisiveness nor of thoughtful consideration. Having encountered my first M$ boot virus circa 1987 ?
    and having seen others experiencing M$ viruses, I am aware of the dangers.

    This thread is unproductive.


    Paul. England, EU. Je suis Charlie.

  • Oh dear. Legal point 1: you do not know the source of the Russian’s PDF.

    Legal point 2: you can not determine with certainty that the said PDF is
    *not* a lawful copy.

    Legal point 3: you can not establish the Russian’s possession of the PDF
    is *not* lawful.

    Legal point 4: Page iv (meaning preface page 4 but physical page 5)

    “Copyright © 2011 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to:
    Pearson Education, Inc. Rights and Contracts Department
    501 Boylston Street, Suite 900
    Boston, MA 02116
    Fax: (617) 671-3447
    ISBN-13: 978-0-13-148005-6
    ISBN-10: 0-13-148005-7
    Text printed in the United States on recycled paper at Edwards Brothers in Ann Arbor, Michigan. First printing, June 2010”

    Legal point 5: You are seriously mistaken in asserting the said PDF did
    *not* originate from the publisher.

    Legal point 6: You have no case to argue.

    Legal point 7: You are unproductively using your own, and other’s, time, interest and energy.


    Paul. England, EU. Je suis Charlie.

  • The person asserting the copy was “pirated” (meaning stolen) has no proof it was stolen. Just because someone jumps up and down shouting various things, can not in law make any of those things a fact.

    To prove something one needs FACTS which is also known as evidence. No evidence exists that the copy was stolen. Justice depends on factual information not people inventing “facts” without proof. If I claimed you were Bill Gates’ brother, would that actually make you Bill Gates’
    brother ?

  • doesn’t matter.

    I know that *I* don’t have the rights to read that PDF, and I suspect you don’t either. Do you have written permission from the copyright holder, Pearson Publishing, to download that ? I see a statement embedded in the work that permission is required to reproduce, store, transmit, etc in any form. Your suggesting on a public forum such as this that a random copy on a random website is an acceptable source of a copyrighted work is immoral and wrong.

  • I don’t think anyone is arguing that point. But if anyone else downloads the PDF from his site, then they are violating the copyright.
    I can only assume you have violated the copyright, as you are quoting from the PDF.

    And you are perpetuating the same. Please let it go, and do not encourage copyright infringement.

  • This thread has gone quite off topic. But as a published author, which should give me no more authority on the subject than anyone else, who happens to have had his copyright ripped off, I have to say that I
    don’t really give a crap. Maybe I give a tiny crap.

    For one, the freeloader problem is well understood economically, and isn’t that big of a problem so long as the price and distribution mechanisms are appropriate in the first place. Second, not everyone on this planet is on the same page (or even book) when it comes to property rights; this can’t be construed to mean “we’re right and they’re wrong”. Someone who buys my book and now has these ideas, who then replicates them with his own physical property (ink and paper)
    really hasn’t cost me anything. The idea I’ve lost sales royalties is sort of a b.s. argument, chances are these people wouldn’t have ever bought the book to begin with. OK, so the argument goes, then these people shouldn’t benefit from these ideas. Well, in my case, they’re not really ideas, they’re facts – it’s a technical book. And you can’t copyright facts. You can only copyright the prose by which those facts are presented.

    An incomplete search suggests the average middle class Russian annual income is around $10k-$15k. This book is 0.2% of that salary. The average U.S. salary is nearly 4x that amount. Does anything think the price of this book is 1/4 the price in Russian? *shrug*

    The whole valuation and pricing of this sort of stuff is bullcrap. It’s a less than a $40 book on Amazon, chances are each author is making much less than $1 in royalties per book. So who’s being ripped off the most by downloading a bootleg PDF? The publisher. The authors aren’t being injured that much.

  • Well seeing as it’s over 1200 pages and only ~16MB, it cannot possibly be scanned. It’s too small a file. If I had to guess, it probably escaped somewhere between whoever did the layout and created the original PDF, and a foreign publisher (I’m assuming this book has been translated into other languages).

    It’s most definitely not a lawful copy. I’m completely certain of this.

    Russia is a UCC signatory, it’s certain it’s not a lawful copy under either international or Russian law.

    It doesn’t matter if the publisher lost containment and the PDF
    escaped into the wild. It’s still copyright infringement to cause copyrighted material to be replicated without permission.

    OK well if you’re going to take the time to make bullshit legal points like this, then I get to say “you sir, may kindly kiss my ass.”

    So are you, and this is your informal invitation to stop.

    Chris Murphy

  • Indeed I should have said “allegedly pirated” not just “pirated”. As I
    don’t care to go into details if it is or it isn’t. I also would recommend to finish this discussion and those who feel so get themselves some fundamental book and go ahead with reading it. Which I’m going to do myself (there are things I need to read…)


    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247

  • On my desk I have a copy of ‘The Book’. I got it free of all costs. It is not mine. I did not buy it or otherwise make a payment to possess it. It has the same copyright notice inside. It does not state “Pirate Copy”
    anywhere on the covers or inside. Hopefully I am lawfully allow to read it ?

    Before an unnecessary riot starts perhaps I should mention I’ve borrowed
    ‘The Book’ from a public library :-)

  • FYI my comments are restricted the PDF floating around of the recommended UNIX and Linux System Admin book. That’s definitely not legit.

    What libraries offer is not only legal, it’s important to keep this intact. Publishers have variably been very unreasonable abrogating the first-sale doctrine when it comes to ebook versions. It’s a case where I believe in no shade of gray. If I’m led to believe I’ve bought an ebook, not merely renting it, then I should have the right to give that ebook to a library, school, friend, leave it in an estate to children. And quite a number of publishers deny this doctrine applies to ebooks. Not good.

  • My considered opinion is:-

    PDF copies, as produced by the publisher, should be sold for no more than USD $ 10.00 per copy with 30% going directly to the author. At present publishers are far too greedy. Their lust for the public’s cash is detrimental to learning generally and to the distribution of knowledge. Many years ago, before I sold my soul to the computer world for GBP £2
    per week extra pay, bookshops received between 45% and 55% discount. PDFs require no storage space in premises, no heating, no building insurance, no public liability insurance, no staffing costs etc. etc. Consequently it is unreasonable for the publisher and/or the distributor to retain most of the income from PDF and other e-book format sales. They are doing virtually no work but profiteering enormously from the author’s hard work.

    Admittedly it is possible for sellers to sell cloned copies of PDFs. However it must be possible to overprint every page in a PDF with a sellers receipt number or publisher’s copy-serial-number which could be entered on a web site when seeking errata and extras associated with possession of the publication – or even registering possession of a copy for future updates and associated information.


    Paul. England, EU. Je suis Charlie.

  • Most phishing sites do not resemble anything like what one might expect. That is why they work. Truly, with network security you really, really have to develop a pathological paranoia about files with unknown origins or you might as well give up on security at all.

    PDFs are known vectors for malware. They have been exploited in the past and no doubt will be exploited in the future. A PDF file is a postscript computer language program with embedded data. Nothing more. But nothing less either. Given the network awareness of some pdf reader software they are also potential data leaks and web beacons.

    That said, I readily admit that the risk posed by this particular example is low. But, it is not zero. And depending upon the platform the file is copied to any non-zero risk, no matter how small, may be too much.

    I might put such a file on a stand-alone laptop but I would never put it on anything that connected to my networks. I certainly would not place it on anything that did not possess a fairly robustly constructed firewall with strict limits on outgoing traffic.

  • As an example, I found and downloaded a spec sheet several years back for a ADVA FSP-II upstream equivalent to the Cisco Metro 1500 wavelength division multiplex platform. This PDF had an embedded Javascript exploit (yes, Adobe Reader does do Javascript) and that Windows machine was pwned in short order (and the user I was running as was not an administrator equivalent). I suspect that using Adobe Reader on CentOS
    could be just as dangerous (in terms of user data exfiltration and/or payload delivery for crypto-ransomware). Privilege escalation is not required for much mischief to be done.

    Random PDFs are and continue to be malware vectors.

  • I viewed the Russian site from a machine with *NO* network connections.

    I sincerely appreciate your well articulated concerns and thank you for them. I am certain others reading your posting will now be increasing aware of the constant dangers which await everyone.

    In my experience a major method of compromising machines is to send naive users an email from Amazon, Ebay, their bank – and in the last few days from all around the world from “” – instructing the recipient to urgently open the accompanying .zip and read the message. Our incoming mail filtering (implemented on Exim) removes more than 99% of spam and crap. Our servers yesterday accepted the first junk mail of this year. It was deleted not read.