On Wed, February 4, 2015 9:17 am, James B. Byrne wrote:
>
> On Tue, February 3, 2015 14:01, Valeri Galtsev wrote:
>>
>> On Tue, February 3, 2015 12:39 pm, Les Mikesell wrote:
>>> On Tue, Feb 3, 2015 at 12:24 PM, Valeri Galtsev
>>> <galtsev@xxxxxxxxxxxxxxxxx> wrote:
>>>>
>>>> Sounds so I almost have to feel shame for securing my boxes no
>>>> matter what job vendor did ;-)
>>>
>>> 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?
>>
>> Do I have to take that people who are not sysadmins themselves just
>> hate an existence of sysadmins?
>>
>
> 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?
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.
>
> We are dinosaurs. People do not hate us. They just do not understand
> why we are still around.
I didn't say sysadmins. My language was deliberate, I said an existence of
sysadmins.
>
> 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.
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.
>
> 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'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 ]
>
> 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.
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).
>
> 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?
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.
>
> 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.
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 ;-)
>
> 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.)
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
>
> Sometimes I just cannot bear to think about this stuff anymore.
>
> --
> *** E-Mail is NOT a SECURE channel ***
> James B. Byrne mailto:ByrneJB@xxxxxxxxxxxxx
> Harte & Lyne Limited http://www.harte-lyne.ca
> 9 Brockley Drive vox: +1 905 561 1241
> Hamilton, Ontario fax: +1 905 561 0757
> Canada L8E 3C3
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
