Thursday, August 31, 2017

Upgraded from Fedora 25 to 26

I've just upgraded my Fedora 25 workstation to Fedora 26.  I had previously upgraded from 23 to 24, then 24 to 25... So far things are working out fairly well and I have not noticed any issues directly related to the upgrade.

Kudos to the Fedora team.

Tuesday, August 29, 2017

Choosing a safe encryption algorithm for SSH on CentOS

How to choose the best possible encryption algorithm for SSH on Centos?

Choosing a stronger encryption algorithm for SSH, than the default:

Regenerate a new host key using the ed25519 algorithm (ed25519 uses Curve25519 which has a high safety rating)
https://safecurves.cr.yp.to/
http://blog.cr.yp.to/20140323-ecdsa.html 

ssh-keygen -f /etc/ssh/ssh_host_ed25519_key -N '' -t ed25519

# vim /etc/ssh/sshd_config

Comment all HostKey lines, except for the key using ed25519:

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Restart the sshd service:

systemctl restart sshd

Sunday, August 27, 2017

A word about sealert

The sealert command can be run both as a CLI or GUI program.  However, when you want to run it from the CLI, it is necessary to specify the path using the -a switch.

For example, here is the result if you run sealert from a TTY:

# sealert
could not attach to desktop process

On the other hand, if you specify the file to scan:

# sealert -a /var/log/audit/audit.log

You will get the expected result.  If any failures were in the logs, they will show up with an analysis, similar to:

--------------------------------------------------------------------------------

SELinux is preventing /opt/brother/Printers/mfcj485dw/cupswrapper/brcupsconfpt1 from execute access on the file /etc/ld.so.cache.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that brcupsconfpt1 should be allowed execute access on the ld.so.cache file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'brcupsconfpt1' --raw | audit2allow -M my-brcupsconfpt1
# semodule -i my-brcupsconfpt1.pp


Additional Information:
Source Context                system_u:system_r:cupsd_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:ld_so_cache_t:s0
Target Objects                /etc/ld.so.cache [ file ]
Source                        brcupsconfpt1
Source Path                   /opt/brother/Printers/mfcj485dw/cupswrapper/brcups
                              confpt1
Port                         
Host                         
Source RPM Packages           mfcj485dwlpr-1.0.0-0.i386
Target RPM Packages           glibc-2.17-157.el7_3.5.x86_64
                              glibc-2.17-157.el7_3.5.i686
Policy RPM                    selinux-policy-3.13.1-102.el7_3.16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     SOMENAME
Platform                      Linux SOMENAME 3.10.0-514.26.2.el7.x86_64 #1 SMP
                              Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64
Alert Count                   20
First Seen                    2017-08-21 18:04:39 EDT
Last Seen                     2017-08-21 18:04:42 EDT
Local ID                      9851dcdd-6b59-4310-8e26-573219f32e7e

Raw Audit Messages
type=AVC msg=audit(1503353082.145:499): avc:  denied  { execute } for  pid=14664 comm="brmfcj485dwfilt" path="/etc/ld.so.cache" dev="dm-0" ino=146770715 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:ld_so_cache_t:s0 tclass=file


type=SYSCALL msg=audit(1503353082.145:499): arch=i386 syscall=lgetxattr per=400000 success=no exit=EACCES a0=0 a1=22671 a2=1 a3=2 items=0 ppid=14608 pid=14664 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=4294967295 comm=brmfcj485dwfilt exe=/opt/brother/Printers/mfcj485dw/lpd/brmfcj485dwfilter subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null)

Hash: brcupsconfpt1,cupsd_t,ld_so_cache_t,file,execute


--------------------------------------------------------------------------------

Thursday, August 24, 2017

libvirtd hook for HOST to GUEST forwarding

I found a minor issue in the hook provided by libvirt documentation regarding Host to Guest forwarding. NOTE: This only applies when the guest is using NAT networking.

Scenario on a CentOS 7 VM host:

A KVM (libvirt) guest provides a specific service on some port, let's say 8080.  The idea is to setup the host to NAT traffic destined to host's ip at a specific port, to the guest IP at a specific host.

Host IP: 192.168.100.10
   port to forward: 8080
Guest: 192.168.122.10
   port listening: 8080

client -> 192.168.100.10:8080 -- Forward --> 192.168.122.10:8080

The libvirt documentation provides the following hook script to deal with exactly this situation:

http://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections

However, there is a problem as the script will never succeed in adding the rules.

The following if statement is never entered as the variable tested against does not match the strings.

   if [ "${2}" = "start" ] || [ "${2}" = "reconnect" ]; then

The variable will contain the word "started" when it hits this if statement.  To fix this, simply add another OR:

   if [ "${2}" = "start" ] || [ "${2}" = "reconnect" ] || [ "${2}" = "started" ]; then

After that change restart libvirtd:

systemctl restart libvirtd

Check to make sure the FORWARD rule was added to the ip chain:

iptables -nL FORWARD 

Note that this does not enable localhost:8080 from the Host to work.  However, the host (in NAT Networking) can still connect to the Guest on its IP at 192.168.122.10:8080

Works well for my purposes.


Wednesday, August 23, 2017

chcon and semanage - specifying user flag

NOTE TO SELF!

While going over some Selinux tools, I noticed some differences in the semantics used to specify similar properties.

In a previous post, I wrote about making changes to a file context temporarily or permanently, using the chcon or semanage fcontext respectively.

The flags to specify the selinux user are different depending on the command you use.  To specify the user for the chcon command, you use the  -u modifier, as in:

chcon -u user_u ...

While, semanage fcontext uses the -s modifier, as in:

semanage fcontext -a -s user_u ...

In the former command, the modifier -u has the obvious mnemonic of "user".

In the latter, the modifier -s actually stands for "selinux user".

Considering the two commands are closely related, it is not so obvious that the semantic changes from one command to another.

Wednesday, August 2, 2017

Libvirtd - VMs on separate virtual networks cannot talk to each other

There is a minor flaw in the way libvirt is configured to add Firewall rules to the host firewall when creating virtual networks.  Two Virtual Machines in separate virtual networks cannot speak to each other bidirectionally.  I am not the only one who has had this problem but it seems that the issue has not caused enough problems for it to be fixed yet.  Or, perhaps I am misunderstanding the way libvirt is supposed to be configured.

Before proceeding, I've read the documentation regarding this issue at: https://libvirt.org/firewall.html

And I've requested assistance from people on IRC  irc.oftc.net, channel: #virt.

Presently I am following examples in Michael Jang's RHCSA/RHCE study guide, specifically: RHCSA/RHCE Red Hat Linux Certification Study Guide, Seventh Edition (Exams EX200 & EX300).  In the first chapters we are instructed in creating a second virtual network (the first being the default.)  Virtual machines are created in both of these networks.  Here is the basic idea of the networking setup:

Host OS: CentOS 7.3
Libvirt version: libvirt-daemon-2.0.0-10.el7_3.9.x86_64

Network Setup:
---------------------------
Host network: 192.168.0.1/24 (this can vary)
Host IP: 192.168.0.27 (this can also vary - statically assigned)

1st Virtual Network (Default):
    Net: 192.168.122.0/24
    GW: 192.168.122.1
    DHCP: yes
    DHCP Range: 192.168.122.2->254    (I use static IPs)
    Forward Mode: Nat

2nd Virtual Network (outsider):
    Net: 192.168.100.0/24
    GW: 192.168.100.1
    DHCP: yes
    DHCP Range: 192.168.100.128->254    (I use static IPs)
    Forward Mode: Nat

VM status in 1st network (Default):
    Name: server1
    IP: 192.168.122.50
    - can ping host fine
    - can ping external DNS addresses (like google)

VM status in 2nd network (outsider):
    Name: outsider1
    IP: 192.168.100.100
    - can ping host fine
    - can ping external DNS addresses (like google)

PROBLEM: Here's where things fall apart; outsider1 can ping server1 just fine, but server1 cannot ping outsider1.

[name@outsider1 ~]$ ping 192.168.122.50
PING 192.168.122.50 (192.168.122.50) 56(84) bytes of data.
64 bytes from 192.168.122.50: icmp_seq=1 ttl=63 time=0.171 ms

[name@server1 ~]$ ping 192.168.100.100
PING 192.168.100.100 (192.168.100.100) 56(84) bytes of data.
From 192.168.122.1 icmp_seq=1 Destination Port Unreachable


Below, I have the modifications made by libvirt to my firewalld FORWARD chain configuration (Sorry for the tiny fonts - zoom in if necessary):

Base FORWARD chain (prior to having libvirtd configure any networks:
-------------------
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
FORWARD_direct  all  --  0.0.0.0/0            0.0.0.0/0          
FORWARD_IN_ZONES_SOURCE  all  --  0.0.0.0/0            0.0.0.0/0          
FORWARD_IN_ZONES  all  --  0.0.0.0/0            0.0.0.0/0          
FORWARD_OUT_ZONES_SOURCE  all  --  0.0.0.0/0            0.0.0.0/0          
FORWARD_OUT_ZONES  all  --  0.0.0.0/0            0.0.0.0/0          
DROP       all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Default Network Added:
----------------------
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        
ACCEPT     all  --  0.0.0.0/0            192.168.122.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     0.0.0.0/0          
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
...

outsider Network Added:
-----------------------
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        
ACCEPT     all  --  0.0.0.0/0            192.168.100.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.100.0/24     0.0.0.0/0          
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
ACCEPT     all  --  0.0.0.0/0            192.168.122.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     0.0.0.0/0          
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
...

According to an individual I spoke to on IRC, the intent was to have the firewall block communication both ways,  meaning that neither VMs should have been able to communicate with each other.

I'm not sure if Michael Jang is aware of this, but it seems that this is not entirely well documented, and not exactly functional either.

Since I want my two VMs to communicate with each other across this network, my temporary solution is to modify the FORWARD chain and remove the two REJECT rules that were added with the 'outside' network.  Therefore we will delete the 4th and 5th rules.

From the host system, as root, delete the 4th rule in the FORWARD chain.

[root@hostname ~]# iptables -D FORWARD 4

Since the 4th rule is deleted, the 5th rule now became the 4th, so verify with:

[root@hostname ~]# iptables -L FORWARD

And delete the new 4th rule (formerly 5th).

[root@hostname ~]# iptables -D FORWARD 4

Verify your final configuration and try pinging from both VMs.

[root@hostname ~]# iptables -L FORWARD

NOTE: Of course, this is a temporary rule for testing purposes only and not meant to be used for a production VM host.  If that is your purpose, a proper firewall configuration design should be undertaken with all that it entails.