Slashdot Mirror

Here - https://access.redhat.com/knowledge/solutions/2474

You can read about license keys and activation nonsense.

This is a very good point. One dumbass user who doesn't keep a passphrase on his private key, doesn't encrypt his hard drive, etc. and bam, you get hosed.

If you're on a current OpenSSH (as available in Red Hat 6.3 at least, or its rebuilds like Scientific Linux or CentOS), you can require both key and password auth. From the release notes at https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.3_Release_Notes/index.html#id3199604:
"SSH can now be set up to require multiple ways of authentication (whereas previously SSH allowed multiple ways of authentication of which only one was required for a successful login); for example, logging in to an SSH-enabled machine requires both a passphrase and a public key to be entered. The RequiredAuthentications1 and RequiredAuthentications2 options can be configured in the /etc/ssh/sshd_config file to specify authentications that are required for a successful log in."

To implement on an SSH server where only SSH protocol 2 is allowed, drop this in your /etc/ssh/sshd_config:

        RequiredAuthentications2 publickey,password

You need to specify PasswordAuthentication yes as well, or you'll be told: "Invalid required authentication list"

Once you set it up, restart your sshd daemon, and you will be good to go.

Nothing's foolproof however, and I mean that in the literal sense of the word "foolproof". Some fool can store his password in plain text on the same system as his key, write his password on his computer in Magic Marker or whatever, and you're screwed again. Allowing SSH access to morons is a major security hole.

Looks like that's the plan: Here's a preliminary patch from Linus, with the ability to configure it coming later on.

It really does seem like theyve gone a bit crazy.... heres a snippet from a bug report on the issue:

[dev gives reasons why it is impossible to probe for drivers to load prior to loading some pieces of firmware]

All that doesn't matter; do whatever you need to do, but load the firmware
async, and continue to do the rest of the job when the firmware arrives, and
do not block modprobe.

Unless Im misreading that, Kay is saying "i dont care that the thing Im asking you to do is impossible, just do i t anyways, because its more correct".

Im not a software dev, so maybe Im misreading this, but everyone seems to agree that what the udev folks are mandating is simply impossible in many instances.

Here's the link, took me a whole two minutes to find it http://ftp.redhat.com/pub/redhat/linux/enterprise/6Workstation/en/os/SRPMS/

If you want something supported for a long time, I would say Centos or Debian are the way to go. And if you wish to sustain developpers, you can either donate to Debian with SPI, or pay for a RHEL subscription, and that benefit to Centos, Scientific Linux, or even OEL, who are all clones of RHEL, and pay for jobs of many upstream developers ( http://www.redhat.com/promo/os-community/projects.html ).

AIX runs on Power7. There also is RHEL for Power7:

http://www.redhat.com/products/enterprise-linux/for-ibm-power/

However, AIX does not run on Mainframe hardware, although you can run Linux on the Mainframe.

So you can run Linux on anything IBM sells, but that is the only OS since OS2 to do it.

Hmm.. not sure why the link was not there..

https://access.redhat.com/security/cve/CVE-2012-0056

It would be interesting to see the median cost savings, vs. average cost savings. For most, I'm guessing that the cost would be rather low - less than the cost of new hardware and setting the system up again if you lose it - but that you have some extreme outliers.

That said, for OS X, Red Hat Enterprise Linux (and similar for others, I'm sure) and Windows 7 it is trivial to enable.

Seen what, a vulnerability? They still show up from time to time.
E.g.:
CVE-2012-0247
CVE-2012-1149
CVE-2012-2806
CVE-2012-2814
CVE-2012-2840

Seen what, a vulnerability? They still show up from time to time.
E.g.:
CVE-2012-0247
CVE-2012-1149
CVE-2012-2806
CVE-2012-2814
CVE-2012-2840

Seen what, a vulnerability? They still show up from time to time.
E.g.:
CVE-2012-0247
CVE-2012-1149
CVE-2012-2806
CVE-2012-2814
CVE-2012-2840

Seen what, a vulnerability? They still show up from time to time.
E.g.:
CVE-2012-0247
CVE-2012-1149
CVE-2012-2806
CVE-2012-2814
CVE-2012-2840

Seen what, a vulnerability? They still show up from time to time.
E.g.:
CVE-2012-0247
CVE-2012-1149
CVE-2012-2806
CVE-2012-2814
CVE-2012-2840

Posting anonymously so I don't get accused of Karma/etc. abuse.

So if you want to do Linux Red Hat is a pretty good Linux vendor to work for (disclosure: I work for them). We're committed to Open Source and better yet we're hiring (we just broke a billion dollars last year and need more people). Go to http://careers.redhat.com (which redirects to icims). Then find a job that is suitable for yourself, many are location specific (Red Hat tends to group certain types of people in offices, e.g. doc writers, kernel guys, product teams). You can apply straight through the web interface but of course your chances are much better if you know someone at Red Hat that can help nudge you/provide a recommendation, cultural fit is an important aspect, so if you have a history of participating in Open Source that's a HUGE advantage (your name in CREDITS, or on web pages and so on, or being known to be helpful on IRC or whatever).

I started using Linux at 17 or so (asj introduced me to it), connected to the Internet via dialup and realized that if I could connect to systems on the Internet they could connect to me (using SLIP/etc I had an actual IP). So I started learning about security, but basically no documentation/etc. existed back then (this would be 18 years ago). So I started keeping notes, back then stuff like disabling stuff in /etc/inetd.conf (remember that file?) was serious high end security, and using tcp_wrappers was Matrix style kung-foo. I then realized I couldn't be the only person with this problem (not knowing anything about security) so I started documenting it, in early 1998 I registered seifried.org and put the docs up (where they remain today, out of date but somewhat useful) at seifried.org/lasg/.

This in turn got me a contract at SecurityPortal which got killed in the .com downfall, then I contracted for iDefense (then Verisign bought them) and then iSIGHT partners where I basically did information security analysis, focused heavily on Linux. But I wasn't super happy, I realized what I really enjoy is writing stuff for the public (not just paying customers). So I decided to go back to my Open Source roots and joined the Red Hat Security Response Team (https://access.redhat.com/security/team/) and CVE guy (e.g. http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html).

Basically in the security community the way (everyone I know) gets hired is they get into security on their own time, do something like build an IDS, or create a secure Linux distribution which is basically their portfolio/resume when it comes to getting hired. Much like the Linux Kernel we don't have a lot of volunteers in the Linux security space, if you're any good at this you tend to get hired quickly. In other words "just do it" and if you are any good at it, a job will not be a problem.

I started using Linux at 17 or so (asj introduced me to it), connected to the Internet via dialup and realized that if I could connect to systems on the Internet they could connect to me (using SLIP/etc I had an actual IP). So I started learning about security, but basically no documentation/etc. existed back then (this would be 18 years ago). So I started keeping notes, back then stuff like disabling stuff in /etc/inetd.conf (remember that file?) was serious high end security, and using tcp_wrappers was Matrix style kung-foo. I then realized I couldn't be the only person with this problem (not knowing anything about security) so I started documenting it, in early 1998 I registered seifried.org and put the docs up (where they remain today, out of date but somewhat useful) at seifried.org/lasg/.

This in turn got me a contract at SecurityPortal which got killed in the .com downfall, then I contracted for iDefense (then Verisign bought them) and then iSIGHT partners where I basically did information security analysis, focused heavily on Linux. But I wasn't super happy, I realized what I really enjoy is writing stuff for the public (not just paying customers). So I decided to go back to my Open Source roots and joined the Red Hat Security Response Team (https://access.redhat.com/security/team/) and CVE guy (e.g. http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html).

Basically in the security community the way (everyone I know) gets hired is they get into security on their own time, do something like build an IDS, or create a secure Linux distribution which is basically their portfolio/resume when it comes to getting hired. Much like the Linux Kernel we don't have a lot of volunteers in the Linux security space, if you're any good at this you tend to get hired quickly. In other words "just do it" and if you are any good at it, a job will not be a problem.

Red Hat offers certifications:
http://www.redhat.com/training/certifications/

If Comment 13 here is right, Fedora Linux reports back every time you mistype a command... https://bugzilla.redhat.com/show_bug.cgi?id=643778#c13

King of virtualization when it comes to things like "supports live migration of a VM's execution state and/or permenant storage", or "stability and speed of the networking layer".

I cant speak to KVM as my experience is limited to VMware, and some HyperV and XenServer testing. But just doing a check from RHEV's own fact sheet, there are a number of things that are missing that are quite useful:
*Storage live migration
*Hot add RAM, CPU
*Hot add NICs, disk (note that RHEV has it wrong-- this does not require anything more than the free hypervisor, NOT enterprise plus as they claim)
*Live VM Snapshots (not really clear how RHEV doesnt have this, even Virtualbox has this)

Those are all pretty core features-- to my mind, ESPECIALLY the disk and NIC hot add. There are a lot of times that it is an absolute blessing to be able to roll out a new VLAN on the network and to just hot-add a NIC to the firewall VM on that VLAN, and your network suffers no outage. With disk, its awfully nice to be able to add a USB disk to the VM without having to reboot the entire thing (again, how does HyperV and RHEV not have this?).

Tim Cook singles out a few patent system issues that have negative effect on Apple (they are using them to sue right now and thus burning money) and calls them bad. He doesn't seem to mind the idea of software and design patents.

Let's assume a company has to "play along" with the system. This is because it's main purpose is to maximise profit, and thus Apple uses patents aggressively and to their full potential.
Now if they didn't the patent system in general (as you claim), they still would act in support of it because they must be "playing along", which turns their critique into hollow words.

Why can't they behave a tiny little bit like Red Hat? Or have you seen Google being the aggressor in a patent dispute? How many other tech giants are initiating patent wars that are not defensive countersuits (OK, you get Microsoft for free)? Oracle did, and they rightfully got a shitload of heat for it.
Apple's currently by far the #1 offender, the champion of the broken software patent system.

To get back to your links... maybe the Apple guys are really against the patent system but believe that working fully "for it" is the way to go. Or maybe Apple just talks the talk: they're critisising that "bad patent system" solely for PR reasons while wallowing in it, in the hope that their marketing is good enough to fix the obvious discrepancy? This would even seem to work ;)

Speaking of making things more difficult than they should be, the ISO images for installation are not readily available for download. There is a heinous registration form but no promise of the ISOs even if you fill in the form (with either fake data or real). If Oracle is going to be serious about establishing a distro, it has got to be available at all the usual download sites along site CentOS, Debian and the other established distros.

Yeah, like you can download RHEL without having to buy a subscription, and without having to register or anything, and its a full version, not some crappy evaluation version. Oh, wait.....

And then there's RedHat's OpenShift that appears to be free forever as long as you don't need much power. I guess that might change if it gets real popular, but then real popular should mean they have a lot of paying customers to subsidise the freebie option.

SRP is great, but it does not eliminate the need for better password hashing - rather, these things may/should be used together. It does not take breaking DH to merely probe candidate passwords against a stolen/leaked SRP verifier. The Wikipedia article you referenced says that "using of functions like PBKDF2 instead of H for password hashing is highly recommended", and they were referring to the password stretching aspect. Other properties of the hashing method are also relevant, just like they are to "regular" password hashes.

In fact, I complained to Tom Wu about SRP's use of non-iterated SHA-1 in 2000, and I had an e-mail exchange on a similar topic in SPEKE context with David Jablon in 1998 or so. Since then (or at about that time), the need for heavy to compute underlying hashes even along with zero-knowledge password proofs became widely recognized. I am not really into the latter topic, but I did my little bit to influence that field in that minor aspect (and I'm sure many others did as well).

Ah, ok - thanks, I managed to miss that. Most of our servers are still on RHEL 5 because of some odd issues we've experienced with LDAP under RHEL 6.

Because goddamn sudoers doesn't work with LDAP since 6.1, when it used to work just fine in 6.0 and now nslcd pukes on the config you need?

Yeah....this is FINALLY patched in 6.3 (a week ago or so). Be aware that you need to change some things and add an additional conf file to make it work. What a pain in the ass, but it's finally over (or will be for me once CentOS gets it downstream).

https://bugzilla.redhat.com/show_bug.cgi?id=760843

Possibly refers to some of the issues covered here: https://access.redhat.com/knowledge/articles/15145?amp

In particular, to this issue, which apparently first materialized with the recent leap second, and probably not to this issue, which might be the one fixed by this patch.

Possibly refers to some of the issues covered here: https://access.redhat.com/knowledge/articles/15145?amp

In particular, to this issue, which apparently first materialized with the recent leap second, and probably not to this issue, which might be the one fixed by this patch.

Possibly refers to some of the issues covered here: https://access.redhat.com/knowledge/articles/15145?amp

In particular, to this issue, which apparently first materialized with the recent leap second, and probably not to this issue, which might be the one fixed by this patch.

Copyrights/brands do not have that much value most of the time, and RH already has a good brand, so adding more may dilute the current one ( see how most of the product are rebranded as RH-something for the enterprise version ).

Patents have value only if you use them, and there is a patent promise on Red Hat website about what they use patent for ( http://www.redhat.com/legal/patent_policy.html ). The company is also one of the founding member of Open Invention Network and likely donated patents to the shared pool. There is also few people paid to work on the topic, such as Jan Wildeboer fighting against IP extremism, as he say on his web site, or Red hat have several time tried to express against software patents. So again, that's likely not a major interest.

And finally, acquiring people is nice, but in most country, people are free to leave a company at will, and I am prety sure there is lots of example of people leaving after being acquired ( I think Oracle/Sun is a prime example of that, given some problem that some managers at Oracle caused ). So again, that's nice but IMHO, still risky.

So all of them may be worth to buy, but that's quite expensive for 1) something you do not use 2) something you fight against and 3) something you may not keep. if you start to be stupid

Existing contracts are a investement, but again, that's limited in time. And there isn't much assets, computers often depreciate soon, offices are rented most of the time.

Once this UEFI Secure Boot thing ramps up over the coming years, it will no longer be possible to wipe a computer for another operating system

Read the UEFI spec. This isn't true. http://www.redhat.com/about/news/archive/2012/6/uefi-secure-boot

RHEL and Centos are not affected by this issue:

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-2122

http://lists.centos.org/pipermail/centos/2012-June/126719.html

http://www.redhat.com/about/news/archive/2012/6/uefi-secure-boot

Cinnamon certainly does. It's under review for Fedora at https://bugzilla.redhat.com/show_bug.cgi?id=771252 . If you're in a hurry, you can get the .src.rpms from there and rebuild them.

Actually, if by "RHEL from 2008" you mean RHEL5 then you were quite wrong. Apparently, redhat promises security updates at last until sometime in 2017:

https://access.redhat.com/support/policy/updates/errata/

Actually Red Hat Enterprise Linux is supported for 10 years out of the box now (versions 5 and 6):

https://access.redhat.com/support/policy/updates/errata/

With an option to purchase an additional 3 years of extended life support (ELS) for a total of 13 years of support

Good luck getting 13 years of support/updates/etc. from any other Linux vendor or project for a specific version

Not only that but another big turn off is that documentation often tends to be non-existent, incomplete, confusing, or simply wrong then, to make matters worse, when inexperienced users venture into the forums looking for guidance, the replies are usually along the lines of RTFM emphasized with varying degrees of condescension. Very rarely will you find a simple, clear set of instructions on how to perform a specific procedure. New users need hand holding but the Linux community will more often than not just throw them to the wolves.

Also, this doesn't only affect inexperienced users. Try writing a program that utilizes the /sys sysfs interface. Some of it is documented, sort of. Good luck figuring out what is stable or not under there.

I always pick on sysfs because it is native to Linux and it's where the kernel should be interfacing with userland stuff for the vast majority of admin folks. If there is any part of Linux that should be stable and documented, THAT'S IT.

Speaking of userland, http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/adding_storage-device-or-path.html
How long are grep and echo going to sufficient for making configuration changes? Why even bother providing a file level interface that isn't explicitly stable?? End users will be using this, not just distros.

1. There is no such thing as a "process monitor" in Linux.

What?

So if its an issue with GCC or glibc, then its good to know theres a lot of regression testing going on...

It would be terrible if the GlibC guys introduced another bug such as this one https://bugzilla.redhat.com/show_bug.cgi?id=638477 (read the entire thread for it to make sense - a change in memcpy had major repercussions).

...he eventually decided to branch out and make his own amps.

What does that mean?

He went and got a degree in electronics? Or he was already an engineer like this guy.

I hate these media "rags to riches" stories. They make it sound like the guy went to Radio Shack (when it was for hobbyists), locked himself in his garage, and popped out a millionaire.

They make it sound so fucking simple - as if anyone could it. They can't. I've tried. I bought into the myth that anyone can get rich - 3 times and I'm failed. Didn't work hard enough? Oh, Please. My wife thought I ran off during those times. I almost lost her.

Do you really know what's marketable. What's cool to you may not be to the other guy.

Work your ass off and there will be copycats and they will have deep pockets to bury you in court when you try to sue for patent infringement.

Oh, patents. $16,000 min. That's for a lawyer to give you something lock solid to keep Wang Chung industries from duplicating you thing and selling it for half the cost - if that.

"Open" invention? Yeah, show me the little guy who made it work - not some big VC backed corp.

That's sound software development advice, I don't disagree with it. I'm not defending reverse memcpy, I'm merely saying that "flash doesn't work when we implement memcpy like this" isn't a good enough reason to change the implementation if the bug is on the flash side.

How about "Flash and some other programs in Fedora don't work correctly when we implement memcpy() like this, and some of them might "not work correctly" in ways that are security holes, and we currently have no tools to reliably analyze C code to catch incorrect use of memcpy(), and the failure modes are not always obvious, so it might be quite a long time before all the code out there is fixed?

No, people shouldn't use memcpy() in calls where the source and destination regions overlap, but if it's going to be a long time before those are all fixed, and if the failure modes can be insufficiently obvious that the bugs might not even be discovered before they do damage, this might be like {warning, car analogy ahead!} going through a traffic intersection with a 2-way stop, on the street without the stop signs, without slowing down and checking for oncoming traffic on the other street, because people shouldn't go through stop signs.

Here lies the body of Jonathan Day,
who died defending his right of way.
He was right, dead right, as he sped along,
but he's just as dead as if he'd been wrong.

I think the key here is that the punishment for violating the C standard isn't that your program fails in an obvious fashion, it fails in a somewhat random fashion. If memcpy() would check for an overlap and abort the process if it discovered it, fine, but, at that point, it could, instead, check for an overlap and punt to memmove() with no loss of performance from the version that aborts in the case where there is no overlap and with a gain of "programs don't just barf mysteriously to the end user" in the case where there is.

So the question is whether the reasons for doing the backwards copy, as mentioned in the cited bug report and items to which it links, are sufficient to justify exposing the bugs in buggy programs such as the Flash player. If the performance benefits aren't large, perhaps they aren't.

...especially if the bugs in question are security bugs. If it turns out that it's too easy for people to use memcpy() when they should be using memmove(), perhaps there are technically good reasons not to have separated them, as long as "technically" includes "psychologically" as well as "computer hardware and software-wise", given that much of the computer software that would use memcpy() and/or memmove() is, for better or worse, written by human beings.

When I wrote about pragmatism I was thinking of this problem where a modification to glibc's malloc() implementation broke the Adobe flash player.

Presumably you meant memcpy(), not malloc(). Somebody at Adobe needs a gentle reminder ("gentle" because I can't say for certain that I always remember that memcpy() is explicitly allowed not to properly copy between overlapping memory regions - "properly" meaning "as if the source region were copied to a temporary buffer and then the temporary buffer were copied to the destination region" - but memmove() is explicitly required to do so) that this is a job for memmove() Man.

So the question is whether the reasons for doing the backwards copy, as mentioned in the cited bug report and items to which it links, are sufficient to justify exposing the bugs in buggy programs such as the Flash player. If the performance benefits aren't large, perhaps they aren't.

When I wrote about pragmatism I was thinking of this problem where a modification to glibc's malloc() implementation broke the Adobe flash player. It is worth contrasting the attitude of Linus Torvalds in that thread with that of the glibc maintainers. I think most reasonable people would agree there is a trade off between supporting broken applications and ensuring things are done right. In this case, it would have cost glibc nothing to make a minor concession.

I understand your point, that it doesn't break anything else to make the concession. That said, this is exactly what I mean by "we need less pragmatism." The way I see it, overlapping memcpy is a bug, so that's what needed to be fixed. You code according to an API, and the moment that applications start depending on how you implement that API internally, you're asking for trouble. Pragmatically, you'd get flash working, but I'd actually be in favor of leaving the backwards copy in there even if it serves no other purpose than to expose bugs in people's code using your library.

I think doing things the right way is more important than getting things working for now, because it prevents things from breaking in the future. More long term planning and less short-term concessions is the way to go. That said, "this doesn't work at all on arm" problem was an actual bug on glibc's side. If he thinks the new way of doing things hurts performance in other architectures, then he can provide the different code paths with optimizations if he cares to do so.

Adobe doesn't need Desktop Linux.

And the Desktop Linux bunch don't think they need flash:
https://bugzilla.redhat.com/show_bug.cgi?id=638477

If I were Adobe I'd only care about the Windows, Apple and Android platforms. That's it. Just based on the responses from the developers in that bug report (with the exception of Torvalds), you know that they're not interested in end user experience. And so they will remain irrelevant.

When I wrote about pragmatism I was thinking of this problem where a modification to glibc's malloc() implementation broke the Adobe flash player. It is worth contrasting the attitude of Linus Torvalds in that thread with that of the glibc maintainers. I think most reasonable people would agree there is a trade off between supporting broken applications and ensuring things are done right. In this case, it would have cost glibc nothing to make a minor concession.

This is not Canonical ( with the alleged 10 millions revenue due to goodies ), the details are on the SEC filling ( http://investors.redhat.com/sec.cfm )

I really wish Redhat had some much cheaper, "updates only" version of their software.. When I worked in Education, we had a version that was $50/year.. I would love something like that for my own personal use.. and maybe a $100/y version for companies..

Actually, this exists! It's $99 and includes "Eclipse, Eclipse Tooling, JBoss Enterprise Application Platform, JBoss SOA Platform, JBoss Enterprise Data Services Platform, JBoss Enterprise Portal Platform, JBoss Operations Network, and one entitlement to Red Hat Enterprise Linux, with built-in development tools, and Red Hat Network Access for development purposes."

https://www.redhat.com/apps/store/developers/

the license is not for production machines though.

Also note that you can get free copies of Red Hat Enterprise Linux if you are an ISV developing software for it:

http://www.redhat.com/partners/become/isv/

I really wish Redhat had some much cheaper, "updates only" version of their software.. When I worked in Education, we had a version that was $50/year.. I would love something like that for my own personal use.. and maybe a $100/y version for companies..

Actually, this exists! It's $99 and includes "Eclipse, Eclipse Tooling, JBoss Enterprise Application Platform, JBoss SOA Platform, JBoss Enterprise Data Services Platform, JBoss Enterprise Portal Platform, JBoss Operations Network, and one entitlement to Red Hat Enterprise Linux, with built-in development tools, and Red Hat Network Access for development purposes."

https://www.redhat.com/apps/store/developers/

the license is not for production machines though.

Also note that you can get free copies of Red Hat Enterprise Linux if you are an ISV developing software for it:

http://www.redhat.com/partners/become/isv/

Red Hat doesn't operate like an "open source" company.
  They're making money precisely because they operate as close to a proprietary company as possible without violating the GPL.

Um, yes it does.

The source code for all their stuff is available for free here: http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/.

They don't have to do that. They are only obligated to provide the source on request for a reasonable copying fee to people to whom they distribute binaries to. Instead, they make it freely available to anyone who wants it, without charging a cent for the bandwidth.

Speaking of cents, you can get CentOS, which is identical to RHEL minus the branding entirely for free because RedHat make the sources available freely. Also, redhat make the sources avaialble for non GPL software which they simply don't have to do.

So, the claim that they are as proprietary as possible is simply false.

Fedora is free, RHEL is not
  https://www.redhat.com/apps/store/desktop/
  http://www.redhat.com/resourcelibrary/articles/articles-red-hat-enterprise-linux-purchasing-guide