Monthly Archives: March 2013

IPTables rules for FreeIPA

Posted on by
7

I end up editing this so much, figure I’d post it here for all to use.  This is the standard IPtables config file augmented with those rules required to let through the protocols supported by FreeIPA

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

#TCP ports for FreeIPA
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443  -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 88  -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 464  -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53  -j ACCEPT

#UDP ports for FreeIPA
-A INPUT -m state --state NEW -m udp -p udp --dport 88 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 464 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Trusts and Role Based Access Control for Open Stack

Posted on by
Reply

Bearer tokens are vulnerable to replay attacks. OK, so what are our options? Something where the user proves, via cryptography that they have the right to actually use the token. It doesn’t matter if it is X509, Kerberos, or something we cook up ourselves, it is going to resolve to proving you have the right to use that token.

If tokens must be validated by the owner, we effectively break the ability of Open Stack to hand around bearer tokens to get work done. We are going to have to get a lot of stuff right in order to keep from breaking things. Fortunately, we now have the tools to work around this, and to better secure an OpenStack system: Trusts and Role Based Access Control.
Continue reading →

Keystone, MySQL and Fedora 18

Posted on by
1

It looks like the access model for MySQL has changed between F17 and F18.

openstack-db fails with a permission on the root user.  However, the following works:

  1. As the keystone user (I suspect the openstack-db call made the keystone user, or maybe that is done by the RPM install?)
  2. run mysql,  (no params, using the default identification, which I assume is PAM based?)
  3. create a user named keystone.
  4. and grant that user perms to create a db. 
su - keystone
mysql

create user 'keystone'@'localhost' identified by 'keystone';
grant all  PRIVILEGES on *.* to 'keystone'@'localhost';

exit mysql and log in as that user:

mysql --user=keystone --password=keystone

Create the keystone database:

create database keystone;

Log out and run the dbsync

keystone-manage db_sync

Obviously, this leaves the DB User with too many permissions, but it is a start.

If I now try to run the command

openstack-db --service glance --init
Please enter the password for the 'root' MySQL user:

Even setting the password in MySQL doesn’t work

UPDATE mysql.user SET Password=PASSWORD('keystone') WHERE User='root' AND Host='localhost';

[root@f18-keystone mysql]# openstack-db --service glance --init
Please enter the password for the 'root' MySQL user:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
Failed to connect to the MySQL server.  Please check your root user credentials.

I tried it with the unix password as well.

Note that I can connect using the following SQL Alchemy URL:

connection = mysql://keystone:keystone@localhost/keystone?unix_socket=/var/lib/mysql/mysql.sock

I think this is preferable to exposing TCP sockets around in the case that the Keystone server and MySQL server are co-located.