Red Hat Enterprise Linux 7.3 is broken!

At least kernel-3.10.0-514.26.2.el7.x86_64.rpm is broken. With it, you will not be able to use a stack size lower than ~4.5MB.

Here’s some reading on why your applications would want to do this:

Here’s an excerpt:

Why do we care?

Security in depth.

First, people make mistakes. Setting reasonable limits keeps a runaway process from taking down the system.

Second, attackers will take advantage of any opportunity they can find. A buffer overflow isn’t an abstract concern – they are real and often allow an attacker to execute arbitrary code. Reasonable limits may be enough to sharply curtail the damage caused by an exploit.

Here are some concrete examples:

First, setting RLIMIT_NPROC to zero means that the process cannot fork/exec a new process – an attacker cannot execute arbitrary code as the current user. (Note: the man pages suggests this may limit the total number of processes for the user, not just in this process and its children. This should be double-checked.) It also prevents a more subtle attack where a process is repeatedly forked until a desired PID is acquired. PIDs should be unique but apparently some kernels now support a larger PID space than the traditional pid_t. That means legacy system calls may be ambiguous.

Second, setting RLIMIT_ASRLIMIT_DATA, and RLIMIT_MEMLOCK to reasonable values prevents a process from forcing the system to thrash by limiting available memory.

Third, setting RLIMIT_CORE to a reasonable value (or disabling core dumps entirely) has historically been used to prevent denial of service attacks by filling the disk with core dumps. Today core dumps are often disabled to ensure sensitive information such as encryption keys are not inadvertently written to disk where an attacker can later retrieve them. Sensitive information should also be memlock()ed to prevent it from being written to the swap disk.

You can try running the following commands:

ulimit -s 4096

and see this output:

-bash: /bin/true: Argument list too long

Really!? Find more at Red Hat Bug 1463241 – rlimit_stack problems after update.

If you’re using this kernel, I suggest you upgrade immediately. Your applications that might be written with these limits set wil fail.


Analyst Mumbo Jumbo about Red Hat

Ahead of the Bell: Red Hat
Monday December 10, 8:08 am ET
Jefferies & Co. Analyst Downgrades Red Hat on Challenges From Competing Technology

NEW YORK (AP) — A Jefferies & Co. analyst downgraded Red Hat Inc., saying competing technologies are nabbing market share and could hurt profit growth, as the software maker deals with rivalry by making acquisitions.

Katherine Egbert in a client note cut her rating on Red Hat to “Hold” from “Buy” and reduced her target price to $19 from $23.

Red Hat will have to work to diversify its business away from its Red Hat Enterprise Linux products, which are based on open-source software, Egbert said. That’s because newer virtualization technologies, which allow businesses to use different computer operating systems on a single server, are replacing Linux servers as companies work to cut costs, Egbert wrote.

Often new servers are shipped with a key competing product from VMware Inc., which is cutting into Linux market share, she added.

But Red Hat is diversifying through acquisitions and could step up this process, Egbert said, which could eat into earnings potential.

This is total bullshit for lack of a better term. What in the hell does VMware have to do with Red Hat? They are new and coming into the Virtualization space! VMware actually allows OS vendors to sell more licenses!

Let’s see here “virtualization technologies, which allow businesses to use different computer operating systems on a single server, are replacing Linux servers as companies work to cut costs” … what the fuck!? So you’re running different operating systems … what operating systems might they be? Windows (costs money), more Linux? Probably! They’ll be running other operating systems … just less computers!

Anyone else with any input on this?[ad#ad-1]

Apache SSL Self-Signed Certificates Without Passphrase

taken from:

Following is a quick listing of the commands you need to use when setting up an SSL key for Apache that doesn’t require a passphrase to be entered during normal operations, and includes a self-signed certificate so you needn’t bother with cert requests and CAs. The sequence of events is to create a 3DES key, remove the passphrase, and then generate a self-signed certificate.

The following commands are to be entered via the command line, with each openssl statement requiring interactive input. Performed on Red Hat Linux, these instructions ought to also work on other flavors of Unix with OpenSSL and Apache installed.

openssl genrsa -des3 -out pass.key 1024
openssl rsa -in pass.key -out server.key
openssl req -new -key server.key -x509 -out server.crt -days 999

cp server.key /etc/httpd/conf/ssl.key/
cp server.crt /etc/httpd/conf/ssl.crt/

apachectl restart

Verifying that Apache has the correct SSL directives and is using the correct key and certificate created above is left as an exercise for the webmaster.

If your system has a Makefile or symlink in the Apache conf directory, you can opt to pursue an earlier method to this madness using the below steps (provided here only for completeness):

cd /etc/httpd/conf
/usr/bin/openssl genrsa 1024 > /etc/httpd/conf/ssl.key/server.key
chmod go-rwx /etc/httpd/conf/ssl.key/server.key
make testcert

Optionally, if you need a server.pem file for a given application, such as courier-imapd, use the following to create the .pem file from the previously created certificate and key:

cat server.key server.crt >server.pem

Using the above method you can enjoy the encryption protection provided by SSL without having to pay a commercial vendor to sign your server keys. If you don’t like the popup presented by some applications (e.g. web browsers) about an untrusted certificate, simply follow the process provided by your application to import or install the certificate, at which point you will no longer have to deal with future dialog boxes regarding an untrusted site.