Blueborne – How to disable Bluetooth in Fedora

Yesterday 2017-09-13 Redhat released infomation about the mitigation of the Blueborne vulnerability in RHEL: https://access.redhat.com/security/vulnerabilities/blueborne.

For Fedora the new updates are probably still in the build queue and/or being QAed by the community. For a quick fix, you can disable Bluetooth similar than in RHEL:

Stopping Bluetooth related service

systemctl stop bluetooth.service
systemctl disable bluetooth.service
systemctl mask bluetooth.service

Disable the Kernel modules

echo "install bnep /bin/true" >> /etc/modprobe.d/disable-bluetooth.conf
echo "install bluetooth /bin/true" >> /etc/modprobe.d/disable-bluetooth.conf
echo "install btusb /bin/true" >> /etc/modprobe.d/disable-bluetooth.conf
echo "install btintel /bin/true" >> /etc/modprobe.d/disable-bluetooth.conf
echo "install btrtl /bin/true" >> /etc/modprobe.d/disable-bluetooth.conf
echo "install btbcm /bin/true" >> /etc/modprobe.d/disable-bluetooth.conf

Removing the Kernel Modules from a running System

  rmmod bnep
  rmmod btusb
  rmmod btintel
  rmmod btrtl
  rmmod btbcm
  rmmod bluetooth

Improve your bash shell working experience

This article shows some hints how to improve your bash shell working experience to reach higher productivity. Just simple shortcuts that are not so well known.

Using the History

The bash history is underestimated when it comes to usability. Here some nice stuff to do with the history.

Search the history

Every command is kept in the history. The simplest way to use the history is using the cursor-up/down keys. Most users are aware or [ctrl]-r. Usually you hit [ctrl]-r (r like reverse search) several times and miss the command, roll your eyes, hit [ctrl]-c and do it again. Why not using forward search with [ctrl]-s in such a case? Well, that suspends your terminal. It comes from the ancient times and is not needed anymore.

Turn off terminal suspension

echo "stty -ixon" >> /etc/profile

Now you can search the history back and forward by using [ctrl]-r and [ctrl]-s.

Using another command with the same last argument

When you i.e. do ls a file and decide to edit it, you don’t need to retype the whole file path or using the mouse to copy-paste it. Use the [Alt]-. (dot) combination. It inserts the last argument used. So after ls -la /tmp/file.txt you type vi [Alt].. Review and hit enter to execute.

You can also reuse other than the last arguments, but this is more complex and does not speed up things a lot, copy-paste with your mouse is usually faster in such a case.

Forgot to sudo?

When you want to cat i.e. /etc/sssd/sssd.conf you need root access. As a normal user, access is denied.

[luc@fedora ~]$ cat /etc/sssd/sssd.conf
cat: /etc/sssd/sssd.conf: Permission denied
[luc@fedora ~]$ sudo !!
sudo cat /etc/sssd/sssd.conf
[domain/example.com]

The !! also called bash bang does the trick. It just repeats the same command as used before which all arguments. Be aware that the command is executed immediately.

Bash can copy-paste as well!

Copy-paste is not only available in graphical environments but in the bash shell as well.

If you need to type some different commands all with the same arguments, cut the stuff. Position the curser to the position on the line from where you want to copy and hit [ctrl]-k. When you want to paste, hit [ctrl]-y.

You may also achieve that using othercommand !*. Using !(bash bang) can be dangerous because the command will be executed immediately, the copy-paste method is more safe.

That also works with single words etc. basically everything where you cut or delete some stuff like [alt]-d, [ctrl]-w, [ctrl]-u

Using an editor for copy-paste from websites and word processors

There are a number of reasons why you don’t want to directly copy-paste to a shell. Sometimes the source content has not properly escaped line ends or its just garbage from word processors. You may want to review and edit appropriately before fire the command. There is a super lazy and convenient trick to do so.

The security usecase

Copy-Paste from a Website is a security nightmare. Copy-Paste the following two lines into an editor and you see what I mean.

Sample command
echo “Dont copy-paste”

Second sample

The HTML code used for that is:

Sample command<span style="font-size: 0; position: absolute; left: -100px; top: -100px"><br>:echo "Dont copy-paste"</span>
Second sample

Nice! Use an editor before pasting anything in a terminal, for the sake of security.

The word processor garbage usecase

Lot of documentation is written in word processors such as Libreoffice, MS-Office and others. They replace double hyphens to a single one and nasty stuff such as single quotes to backticks. Just for a thing called usability.

When copy-paste that stuff, you probably want to review and edit it first.

Set the EDITOR environment variable

If you are too lazy to fire up vim, you can set the EDITOR environment variable to an editor of your choice (vim, emacs, nano, whatever), system wide in /etc/profile or /etc/bashrc. A better idea is to put it in ~/.profile or ~/.bashrc.

echo "export EDITOR=vim" >>: ~./bashrc

Afterwards you can just hit [ctrl]-x-e and vim starts up. When save and exit vim, the command will be executed.

What are my Keybindings?

If you wonder what kind of shortcuts are defined in a shell, a lot are. use bind -p to show them.

Have fun 🙂

Manually enroll SLES12 systems to Redhat IdM

RHEL and Ubuntu systems leverage the ipa-client software to easily enrolled them to a Redhat IdM system. Unfortunately SLES12 lacks the required packages. Nevertheless, SLES12 systems can be enrolled manually. This article is about how to achieve this.

Why using IPA for SLES systems?

Most organizations are not pure RHEL or pure SLES shops, the reality shows a heterogeneous mix of Linux distributions in corporate data centers. It makes sense to use the same authentication and authorization system to manage them.

Disclaimer

All the “special” behavior of SLES12 is based on SP2 without any patches, I do not have a SLES subscription for this test. Some of this behavior may have been fixed.

Before touching any system, please have a valid backup ready, just in case.

Preparation work

IPA is picky when it comes to host names, they must be fully qualified. Unfortunately, the default for SLES systems is to use the short host name, this must be changed first, otherwise the functionality will be limited (besides that short host names are a potential security thread).

sles12sp2:~ # hostnamectl set-hostname $(hostname -f)

In case hostname -f does not work, check if the fully qualified host name is set to the primary IP address in /etc/hosts and try again.

Unfortunately this will not survive a reboot, a dirty hack is needed. If someone has a better idea, please let me know.

sles12sp2:~ # echo 'echo $(hostname -f) > /proc/sys/kernel/hostname' >> /etc/init.d/boot.local

Please ensure that system time is correct as Kerberos is picky about having the time in sync with the KDC.

Install the required software

SLES12 comes with the basic IPA libraries and the sssd plugin needed. It just lacks the ipa-client.

sles12sp2:~ # zypper install sssd-ipa sssd-tools sssd-krb5 krb5-client sssd-ad

All dependencies will be installed automatically.

Enable sssd start at boot time, as it is not by default

sles12sp2:~ # systemctl enable sssd

Remove nscd, caching will be done by sssd.

sles12sp2:~ # zypper remove nscd

Log out and in again to get /usr/lib/mit/ in the PATH environment.

Adding the host to IPA

[root@ipa1 ~]# ipa host-add --ip-address=192.168.100.115 sles12sp2.example.com 
----------------------------------
Added host "sles12sp2.example.com"
----------------------------------
  Host name: sles12sp2.example.com
  Principal name: host/sles12sp2.example.com@EXAMPLE.COM
  Principal alias: host/sles12sp2.example.com@EXAMPLE.COM
  Password: False
  Keytab: False
  Managed by: sles12sp2.example.com
[root@ipa1 ~]# 

Generating the Kerberos Keytab and copy it to the destination host

[root@ipa1 ~]# ipa-getkeytab -s ipa1.example.com -p host/sles12sp2.example.com@EXAMPLE.COM -k sles12sp2.example.com.keytab
Keytab successfully retrieved and stored in: sles12sp2.example.com.keytab
[root@ipa1 ~]#  

Copy the Keytab to the system:

[root@ipa1 ~]# scp sles12sp2.example.com.keytab sles12sp2.example.com:/etc/krb5.keytab

Ensure ownership and permissions are set correctly

sles12sp2:~ # chmod 0600 /etc/krb5.keytab
sles12sp2:~ # chown root:root /etc/krb5.keytab

Configuration

Usually Yast is a quite nice tool to configure a SLES system. Unfortunately Yast is very confusing when it comes to SSSD configuration. Lets do it manually.

Get the IPA CA certificate

sles12sp2:~ # mkdir /etc/ipa
sles12sp2:~ # wget http://ipa1.example.com/ipa/config/ca.crt -O /etc/ipa/ca.crt

/etc/krb5.conf

sles12sp2:~ # cat > /etc/krb5.conf << EOF

[plugins]
 localauth = {
  module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so
 }


[libdefaults]
  default_realm = EXAMPLE.COM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  dns_canonicalize_hostname = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  canonicalize = true
  default_ccache_name = KEYRING:persistent:%{uid}

[realms]
  EXAMPLE.COM = {
    pkinit_anchors = FILE:/etc/ipa/ca.crt
    pkinit_pool = FILE:/etc/ipa/ipa.crt

  }

[domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM
  $(hostname) = EXAMPLE.COM
EOF

/etc/sssd/sssd.conf/

sles12sp2:~ # cat > /etc/sssd/sssd.conf << EOF
[domain/example.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = $(hostname)
chpass_provider = ipa
ipa_server = _srv_, ipa1.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh

domains = example.com
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[ifp]

[secrets]
EOF

Ensure ownership and permissions are correct:

sles12sp2:~ # chown root:root /etc/sssd/sssd.conf
sles12sp2:~ # chmod 600 /etc/sssd/sssd.conf

Restart sssd

sles12sp2:~ # systemctl restart sssd

nsswitch.conf and PAM

Enable sssd

sles12sp2:~ # pam-config --add --sss

Enable automatic homedir creation on first login

sles12sp2:~ # pam-config --add --mkhomedir --mkhomedir-umask=0077

Change nsswitch.conf to use sssd

sles12sp2:~ # sed -i 's/passwd: compat/passwd: compat sss/g' /etc/nsswitch.conf
sles12sp2:~ # sed -i 's/group:  compat/group: compat sss/g' /etc/nsswitch.conf
sles12sp2:~ # echo "sudoers: sss" >> /etc/nsswitch.conf

Configure sshd and ssh to use GSSAPI for authentication

sles12sp2:~ # cat >> /etc/ssh/sshd_config << EOF
GSSAPIAuthentication yes
EOF
sles12sp2:~ # cat >> /etc/ssh/ssh_config << EOF
GSSAPIAuthentication yes
EOF

Reboot to ensure its all working and caches are clean

sles12sp2:~ # reboot

Further readings

Conclusion

Using IPA for authenticating users on SLES systems works, but it is not as comfortable as with RHEL, Fedora and Ubuntu. Suse should include the ipa-client in its distribution.

Enrolling SLES systems is not easy to automate without the ipa-client, probably Ansible could help here.

The functionality is almost the same to that for RHEL7, HBAC (host based access control) is working as expected, the same applies to centralized sudoers. Unfortunately the sssd-tools are quite outdated, sss_cache -E will not delete the sudoers cache. Suse should rebase sssd to the latest upstream version. Suse customers can file a request for enhancement in the SUSE Customer Center 😉

Have fun 🙂

Upgrading Redhat Satellite 5.7 to 5.8

Couple of days ago, Redhat released its latest and last major upgrade for Satellite 5.x. Its a rather important upgrade, you are advised to upgrade soon.

This upgrade contains some major improvements like stated in an earlier article

Disclaimer

I’m not responsible for any damage caused by the procedure provided here. Always create a backup before even thinking about upgrading a Satellite server.

Preparation

As always when you plan to upgrade your Satellite server to the latest version, you need to do some preparations first.

Ensure you will have enough disk space free in /var/opt/rh. The upgrade to 5.8 will also install a new PostgreSQL version located at /var/opt/rh/rh-postgresql95/lib/pgsql. The new version will roughly use the same diskspace as the old version 9.2 in /opt/rh/postgresql92/root/var/lib/pgsql.

Download the ISO

Visit https://access.redhat.com/downloads/content/250/ver=5.8/rhel—6/5.8/x86_64/product-software and make sure you select 5.8 and the architecture fitting you system (x86_64 or S390)

Get a new Satellite Certificate Manifest

Satellite 5.8 switches from Certificates to Manifests like Satellite 6. You need a Manifest to get it activated. You can create it by your own at the Subscription Management Application site, ensure you attach enough subscriptions to your Satellite server(s).

Backup

Usually an upgrade runs smooth, but just in case… it is recommended practice to have a recent backup ready. If your Satellite is running on a virtual machine, power off, snapshot and power on to have a consistent backup ready. For physical systems, db-control and the choice.

Backup the rest of your Satellite:

Create a copy of your rhn configuration directory as we need some information from the old files after the upgrade.

rhnsat:~# cp -rp /etc/rhn/ /etc/rhn-$(date +"%F")

Update your OS and Satellite 5.7

First step is to update the operating system and the Satellite 5.7 and apply the latest database schema updates as well.

rhnsat:~# yum -y update && reboot

Update the database schema if needed

To update the database schema, run the following command. Ideally it looks as follows:

rhnsat:~# spacewalk-schema-upgrade 
Schema upgrade: [satellite-schema-5.7.0.27-1.el6sat] -> [satellite-schema-5.7.0.27-1.el6sat]
Your database schema already matches the schema package version [satellite-schema-5.7.0.27-1.el6sat].
rhnsat:~# 

Switch from RHN to Subscription Manager

It is important to ensure you switched from RHN to subscription manager before doing the upgrade. You can check if this is the case with:

rhnsat:~# subscription-manager repos --list-enabled
+----------------------------------------------------------+
    Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID:   rhel-6-server-rpms
Repo Name: Red Hat Enterprise Linux 6 Server (RPMs)
Repo URL:  https://cdn.redhat.com/content/dist/rhel/server/6/$releasever/$basearch/os
Enabled:   1

Repo ID:   rhel-6-server-satellite-5.7-rpms
Repo Name: Red Hat Satellite 5.7 (for RHEL 6 Server) (RPMs)
Repo URL:  https://cdn.redhat.com/content/dist/rhel/server/6/$releasever/$basearch/satellite/5.7/os
Enabled:   1

rhnsat:~# 

If this is not yet done, have a look at the knowledge base article located here: https://access.redhat.com/articles/2884191

Functionality Check with the old version 5.7

It is recommended to restart and check a software functionality before upgrading to be able to pinpoint problems if there are some.

rhnsat:~# rhn-satellite restart

Cleanup

Review the software channels in use and delete unused channels as this can free up quite some disk space and reduces the size of the database significantly.

rhnsat:~# spacewalk-remove-channel -c rhel-i386-rhev-agent-6-server
Deleting package metadata (20):
                  ________________________________________
Removing:         ######################################## - complete
rhnsat:~# 

Delete old system snapshots which are not used anymore. The following example deletes all snapshots which are older than one month:

rhnsat:~#  sw-system-snapshot --delete --all --start-date 200001010000 --end-date $(date -d "-1 months" "+%Y%m%d0000") 

Check for old MD5 user passwords and certificates

Check if there are still some users with an md5 hashed password. The same applies to certificates.

rhnsat:~# spacewalk-report users-md5
rhnsat:~# spacewalk-report system-md5-certificates

If there are any, please have a look to https://access.redhat.com/documentation/en-us/red_hat_satellite/5.8/html/installation_guide/ch10s03

RTFM

If not done yet, install or update the rhn-upgrade package which contains the instructions how to proceed.

rhnsat:~# yum -y install rhn-upgrade

The package contains not only SQL- and other useful scripts needed for the upgrade but also important documents to read. The are located in /etc/sysconfig/rhn/satellite-upgrade/doc.

For most users, the document satellite-upgrade-postgresql.txt applies.

Do not forget to read the updated product documentation as well:

Performing the upgrade

rhnsat:~# mount satellite-5.8-rhel-6-x86_64-dvd.iso /mnt  -o loop
rhnsat:~#  cd /mnt
rhnsat:/mnt# ./install.pl --upgrade
* Starting Red Hat Satellite installer.
* Performing pre-install checks.
* Pre-install checks complete.  Beginning installation.
* RHSM Registration.
** Registration: System is already registered with RHSM.  Not re-registering.
* RHSM Subscriptions.
** Subscriptions: Subscription providing 'Red Hat Satellite' already attached.
** Subscriptions: Subscription providing 'Red Hat Enterprise Linux Server' already attached.
** Subscriptions: Disabling all RHSM repositories (rhel-6-server-rpms, rhel-6-server-satellite-5.7-rpms).
** Subscriptions: All repositories disabled.
** Subscriptions: Enabling RHEL repository.
** Subscriptions: RHEL repository enabled.
* Upgrade flag passed.  Stopping necessary services.
* Purging conflicting packages.
* Checking for uninstalled prerequisites.
** Checking if yum is available ...
There are some packages from Red Hat Enterprise Linux that are not part
of the @base group that Satellite will require to be installed on this
system. The installer will try resolve the dependencies automatically.
However, you may want to install these prerequisites manually.
Do you want the installer to resolve dependencies [y/N]? y
* Installing Satellite packages.
Warning: more packages were installed by yum than expected:
        python-backports
        python-backports-ssl_match_hostname
        python-chardet
        python-requests
        python-urllib3
* Now running spacewalk-setup.
* Setting up SELinux..
** Database: Setting up database connection for PostgreSQL backend.
*** Upgrading embedded database.
** Database: Populating database.
** Database: Skipping database population.
* Configuring tomcat.
* Setting up users and groups.
** GPG: Initializing GPG and importing key.
* Performing initial configuration.
* Activating Red Hat Satellite.
** Manifest not activated.
** Upgrade process requires the manifest to be activated after the schema is upgraded.
* Configuring apache SSL virtual host.
Should setup configure apache's default ssl server for you (saves original ssl.conf) [Y]? 
* Configuring jabberd.
* Creating SSL certificates.
** Skipping SSL certificate generation.
* Deploying configuration files.
* Update configuration in database.
* Setting up Cobbler..
Cobbler requires tftp and xinetd services be turned on for PXE provisioning functionality. Enable these services [Y]? 
This portion of the Red Hat Satellite upgrade process has successfully completed.
Please refer to appropriate upgrade document in /etc/sysconfig/rhn/satellite-upgrade
for any remaining steps in the process.
rhnsat:/mnt# 

Active and Updating the Satellite

Since the ISO image is always a bit outdated, you need to activate and update the Satellite after its installation.

Upgrading the Database schema

rhnsat:~# rhn-satellite stop
rhnsat:~# /etc/init.d/rh-postgresql95-postgresql start
rhnsat:~# spacewalk-schema-upgrade
rhnsat:~# rhn-satellite-activate --manifest=/root/manifest.zip --ignore-version-mismatch

Some more work to do

After the upgrade succeed there is some work work to do.

Initial Sync with CDN

Unfortunately cdn-sync does not inherit the history which channels have been synced previously with satellite-sync. You need to once sync each channel again. Only missing data will be downloaded.

rhnsat:~# for i in $(spacecmd -u admin -p secret -q softwarechannel_listbasechannels); do cdn-sync -c $i; done
rhnsat:~# for i in $(spacecmd -u admin -p secret -q softwarechannel_listchildchannels); do cdn-sync -c $i; done

If you have custom channels, this will produce errors as the custom channels are not available in CDN. Just ignore them.

Rebuild the search index

rhnsat:~# service rhn-search cleanindex

Have fun 🙂