Category security

Grumpy thots on SELinux

I just spent an hour trying to get a Samba share running on Fedora 20.
It used to not take that long, I’m familiar with how to get Samba running,
how to create shares, and how to manage valid users and masks.

But when it still doesn’t work? Well, what other thing do you do–you
TURN OFF SELinux. Why do the Fedora guys wonder at the SELinux hate?
Because SELinux doesn’t return any hint that SELinux policy violations
are the root cause of the strange errors you get when doing even mild
customizations of services…like adding a Samba share.

Please…why cannot I see something like:

smbd: SELinux policy prohibits read of /home/jed/3plibs

?

Would that be so difficult? I guess those things get reported in SOME log, but
NOT IN THE LOG YOU LOOK AT, which is the logs for the service you are configuring.

Your passwords are at risk

Image
Your website and email passwords might have been captured. Your website sessions can be impersonated because cookies can be captured. If you haven’t heard about this the last few days, this is a real uproar on the Internet.

I’ve spent the last two days listening to podcast after podcast describing the technical details of the computer programming flaw that allows attackers slurp unprotected memory from websites, Tor nodes, and IMAP email servers. Thousands of websites have patched their web servers but millions more email and web servers are going to be slow to patch their services.

Go install Lastpass. Use it’s Security Report feature. Create new passwords for sites that have fixed themselves against the Heartbleed bug.

Checking for your ssh-agent on login – updated

The first thing my .bash_aliases file does on login is to check if I’m running ssh-agent and if so, stick that into my shell environment. If not, kick it up, and update a reminder to it. This morning I found a flaw in that, so I believe this is the fix.

  4 export SSH_RECENT="$HOME/.ssh/recent"
  5 [ -f "$SSH_RECENT" ] && eval `cat $SSH_RECENT`
  6 RUNNING_AGENTS=0
  7 if [ ! -z "$SSH_AGENT_PID" ]
  8 then
  9    RUNNING_AGENTS=`pgrep -u $(id -u) ssh-agent | grep $SSH_AGENT_PID | wc -l`
 10 fi
 11 if [ $RUNNING_AGENTS -lt 1 -a $UID -ne 0 ]
 12 then
 13    eval `ssh-agent`
 14    echo "export SSH_AGENT_PID=$SSH_AGENT_PID" >    $SSH_RECENT
 15    echo "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK" >>   $SSH_RECENT
 16 fi
 17 [ `ssh-add -l | fgrep -v ' no ' | wc -l` -eq 0 ] && ssh-add

Quick analysis of Linux’s use of RDRAND. // Pastebin.com

In the presence of the NSA’s aggressive campaign to weaken or break encryption, reducing the actual randomness provided by Intel processors  is entirely within their budget.

Also consider that is is possible to double-mask a processor and add secertly doped regions underneath the silicon to pull down gates. This kind of secret logic is also a logical control mechanism for a processor to use in this kind of subversion of encryption strength.

[C] // This is a quick analysis of Linux’s use of RDRAND. All double-slash // // – Pastebin.com.

 

 

Linux Random Numbers

This explanation from the article comparing /dev/urandom and /dev/random is priceless admin info:

The kernel RNG produces two user-space output streams. One of these goes to /dev/urandom and also to the kernel itself; the latter is useful because there are uses for random numbers within the kernel. The other output stream goes to /dev/random. The difference between the two is that /dev/random tries to estimate how much entropy is coming into the system, and will throttle its output if there is insufficient entropy. By contrast, the /dev/urandom stream does not throttle output, and if users consume all of the available entropy, the interface degrades to a pure CSPRNG.

via LCE: Don’t play dice with random numbers [LWN.net].

Bellingham Air Museum

I like the phrase “starter crank.” I loved planes as a boy, but now I’m bitter about the symbolism. Is this an attempt to poke at jingoism? I love the tone of the shiny metal, truly.

Image

HIgher res available.

Win your election using a MITM attack

Electronic voting has very little to do with computers as we use them today, that is, our web-sites are porous and our networks are fungible, our browsers are petri dishes for crime to grow spores in. So when using conventional networking and typical corporate policies, of course, you just design in the backdoor in plain sight. http://www.truth-out.org/print/4465 A real electronic election system would look nothing like what we use today, and we will not see a good electronic voting system until we are brave enough to actually build something as fundamentally independent from the Internet as our water or gas mains are.