The recent high-profile “Meltdown” and “Spectre” security event did more than expose newly-discovered problems in processor architectures dating back decades. It also exposed gaps in the Security Lifecycle Program for many organizations, possibly even in your own.
linux
Next meeting of the Greater Hartford GNU Linux Users Group
The next GHGLUG social gathering has been scheduled for 2/20 at the Corner Pug in West Hartford, and the next meeting on 2/26 at Axis901 in Manchester. If you are in the Greater Hartford area, and have a personal or professional interested in Linux, please check the Meetup page and join us!
http://www.meetup.com/GHGLUG/
One of those “D’oh” moments: chown .*
UPDATED: Repair process below
Want to change the ownership of all files in a directory to a user named ‘foo’? Think this is a good way to do it?
chown -R foo * .*
Yeah, don’t do that. In one of those awesomely awful “D’oh” moments, I did that. Remember: “.*” matches “..”. So that will traverse up one level, and then recursively back down.
And of course …. I ran this in /mnt . It took me about 5 seconds to realize what I had just done, before hitting ^c. Yeah, my system is b0rked. 🙁
Resolution provided by Simon Sekidde at Red Hat:
On Red Hat Enterprise Linux (and derivatives), there is an easy way to re-initialize the ownership and permissions of RPM-installed files:
for i in `rpm -qa`; do rpm --setugids $i; rpm --setperms $i; done
Make sure to use –setugids before –setperms; if the order is reversed, changing the ownership with –setugids will reset any suid/sgid bits set by –setperms.
Greater Hartford GNU/Linux Users Group
Are you in the Hartford area, and have an interest in Linux and FOSS, and want to meet a group of like-minded people? Come join the Greater Hartford GNU/Linux Users Group!
I attended for the first time last night (2014-01-30), and will look to attend regularly (monthly). Checkout the Meetup page: http://www.meetup.com/GHGLUG/
One Year
Today marks the completion of a full year at Red Hat. It has been an incredible year! I find myself positively challenged daily, working with some of the smartest people I have ever met — both my colleagues within Red Hat, and the customers I get to work with. I get the privilege of being able to work with Open Source technologies, and bring them to a great variety of enterprises. And I have even found my niche within Red Hat’s Identity Management space (imagine that!).
I do miss my team and other friends at UConn. UConn gave me great opportunity, both to gain strong technical skills, and to experience leadership, both formally as management, and informally as a mentor and vocal innovator. I place great value in those first 13 years of my professional career, and I look forward to achieving similar gains in my next 13 years!
Cameo on Gordon Haff’s Cloudy Chat Podcast
(Warning: Shameless Plug)
I recently had the opportunity to join Gordon Haff ( Red Hat’s Cloud Evangelist ) and Ellen Newlands ( Red Hat’s Security and Identity Product Management) for a discussion about Identity Management and Cryptography. Check out what we had to say (audio or text) on Gordon’s Cloudy Chat Podcast .
Timestamping your Bash History
Great post titled Remember when you issued that command…? by Mitch @ UConn on how to include the date/time of each command in your Bash history.
My preference is for ISO8601 time formatting, so I am using:
$> echo 'export HISTTIMEFORMAT="%F %T "' >> ~/.bash_profile
But of course, any ‘date’ formatting will work ( see “man date” for more information ).
Need to deploy a quick JASIG CAS demo? Try jasig-cas-quickdemo!
My development activities on mod_auth_cas have significantly reduced over the past couple of years. In trying to reinvigorate my development cycles around mod_auth_cas, I needed to deploy a CAS server. Deploying CAS is already pretty straightforward — install Tomcat, generate SSL certs, deploy the CAS war, and enjoy. However, I wanted to automate this process to make it easier to repeatedly redeploy a completely clean environment.
So, I have just posted jasig-cas-quickdemo to GitHub.
jasig-cas-quickdemo is a Maven project that does the following:
- Downloads and builds the JASIG CAS project,
- Uses the Maven Tomcat plugin, download deploy Tomcat 7,
- Generates an SSL cert for HTTPS access, and exports the public cert in PEM format for use by CAS clients,
- Launch CAS on the local Tomcat 7 instance, with the default username=passwored authenticationHandler,
- Grants access to the ‘admin’ account for the Services Management interface.
Try the following on Fedora 19+:
$ yum install maven git $ git clone https://github.com/forsetti/jasig-cas-quickdemo.git $ cd jasig-cas-quickdemo $ mvn integration-test
Then just point your browser to https://localhost:8443/cas , and you should see the default CAS login screen.
Check out the README for more information.
Recover a Corrupted Partition Table
You ever have one of those days, where you are happily using your Linux laptop, shut it down for transportation, then fire it up and it just doesn’t boot? I’ll admit that I do all sorts of screwy things on my laptop, so this is probably my own fault, but I figured I’d write it up in the hopes that it helps someone else, and to give a couple shout-outs to helpful resources.
I am running a Lenovo Thinkpad T430s with Red Hat Enterprise Linux 6.4 Server. I have a 256GB SSD, which has a 512M boot partition, and the rest is a LUKS encrypted PV, with several LVs for my filesystems.
I booted the laptop and received a black screen with only two words in white on it:
Error 17
Yep, that’s it, nothing more. Guessing that “Error 17” is a GRUB error (confirmed by Google), I grab my trusty RHEL6.4 USB installer (created with livecd-tools), and boot into rescue mode. A quick fdisk -l shows me a perfectly valid partition layout with a single ~5.5GB partition …. wait, that doesn’t seem right.
So, let me go check my partition table backup that I make periodically. Heh, yeah right.
I vaguely recall my drive layout was as I described above in the second paragraph, but how the heck am I suppose to confirm if my data is still in place (please let this be just a corrupt partition table!!!), and then figure out the partition boundaries and reconstruct the table?
Googling brought me to a posting on Dedoimedo, which pointed me to the awesome TestDisk utility by CGSecurity. I grabbed the Linux x86_64 binary package provided by the site, and followed the CGSecurity TestDisk instructions to analyze my disk. Sure enough, it found the first partition 512MB, and then a second 2MB partition. I read a little about how TestDisk works, looking for signatures for ext2,ext3,ext4,FAT, btrfs, etc., so I understood that it found my first partition which was ext4, but it didn’t know what to do with my LUKS partition. I was pretty sure that the first one was correct, though, so I went ahead and let TestDisk write a new partition table.
Then I fired up fdisk -cu , and deleted the 2nd partition, then recreated it starting at the sector following the first partition, and extending to the last sector on the disk. I was pretty certain that I had used the rest of the disk …. but still added a healthy dose of finger-crossing.
I wrote the disk partition out, rebooted into rescue mode again, found my way to a shell, and attempted to mount the first partition – success!
Next, I proceeded stepwise to access the second partition:
#> cryptsetup isLuks /dev/sda2 #First, test to make sure this is recognized as a LUKS device -- it was! #> cryptsetup luksOpen /dev/sda2 foo #Open the LUKS encrypted device as new device "foo" #> pvs #Scan for LVM PVs, which foo should be -- and it was found! #> vgchange -ay #Activate all LVM VGs on discovered PVs -- and my VG was found! #> lvs #Scan for LVM LVs -- and mine were found
At this point, I mounted my home LV, and was able to take a backup. Feeling brave, I gave the laptop a reboot, and everything is running as before.
So, thank you to Dedoimedo for pointing me towards TestDisk, and thank you to CGSecurity for the great tool!
Using Google Chromecast from Fedora 19
Using Chrome’s Google Cast with the Google Chromecast from an IPTables-enabled Linux distribution can be a bit tricky.
The extension starts by issuing an SSDP request from a local ephemeral UDP port to 239.255.255.250 port 1900. The Chromecast will respond from its IP and another ephemeral UDP port, back to your source UDP port.
IPTables cannot track this simply as “RELATED”, given that the target of the first packet is the multicast address, while the source of the response packet is the Chromecast’s IP. And unfortunately, there is no SSDP conntrack module (at least, not that I am aware of, at the time of writing this post).
Therefore, the best we can do for now is to open the ephemeral port range on the client machine. The list of ephemeral ports, as defined by your Linux machine, can be found by:
cat /proc/sys/net/ipv4/ip_local_port_range
Fedora19 uses firewalld, so you will want to use the following:
firewall-cmd --permanent --add-port=32768-61000/udp firewall-cmd --reload
Given the wide range of ports being opened, you may want to restrict access to just your local network. Consider using Network Manager to associate your NIC (eth0,wlan0, whatever) with your “home” zone, and use the following command instead of the above:
firewall-cmd --permanent --zone=home --add-port=32768-61000/udp
On non-firewalld systems, use this IPTables one-liner (modifying 192.168.0.0/24 as appropriate for your home network):
iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 32768:61000 -j ACCEPT
Launch Chrome, click the Cast extensions, and it should now “Just Work”. And if it doesn’t …. please let me know in the comments on this post.
UPDATE 20150803 – A few additional notes inspired by the great comment from mauriciograciag:
Note the use of the “–zone=home” parameter in the second firewall-cmd example above. This can be a more secure option, but does require ensuring that you have a zone named “home”, and that Network Manager associates your active network profile with this zone. If the Network Manager configuration is in place, I do recommend using that option for those working from systems (laptops) that might also find themselves on alternate networks. However, for desktops that will not be connected to other networks, use of a zone will likely not add any tangible benefits.
If you set these rules via firewall-cmd and wish to revert them, the following should do the trick:
firewall-cmd –permanent –remove-port=32768-61000/udp firewall-cmd –permanent –zone=home –remove-port=32768-61000/udp firewall-cmd –reload
And lastly, note that the iptables rule must be run as root. Typically, this will be done by updating the iptables startup configuration for your favorite Linux distribution (e.g., you may need to add that line to /etc/iptables); but you might also want to run this a single time, non-persistently, from the command line. If you have configured sudo appropriately on your Linux systems, preceding the iptables command with “sudo” would work as follows:
sudo iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 32768:61000 -j ACCEPT