The bullshit of security in mind first before coding.

Today's trolling with code topic is a kick in dee nutz of the « software urbanists security architects from space ».

I had a long beef with these « experts » that basically want to control everything you do while being totally pedantic idiots. They are often Ivy leagues student with a degree in Computer Security that define themselves as white hat.

One of their claim is to be embedded in design decision early to make sure new products are secured. Let's prove this claim is utter bullshit by « over securing » (one way that is a tad trollesque) a clear text protocol which server is in bash.

To wrap up : And today is the grand finale wrapping it up : we secure the service as a second thought.

Define « securing », pliz



In the head of the software architect securing is :
  • confidentiality (making sure evedropping is tough)
  • AAA
    • Authentication : people must be identified to use the service
    • Authorization (also called Role Based Accounting) : you must be able to have distinct users that don't see each others
    • Accounting : login/logout must be logged in a « standard way » that can be consolidated on an external computer
  • containerisation : if your service is broken, you should ensure your whole infrastructure is not compromised
  • it should avoid ressource exhaustion
  • you should provide safe API to the users
Of course, a bash script according to all the « ready made thinking » of this smart asses does not elect to the category of « good enough », and to add insult to injury a Prototype made to work on stdin/stdout.

Thus, now, let's secure it.

SSL tunneling : I love socat bis, terse documentation, but SO ... GOOD



We EXACTLY Follow the certificate generation such as written here : http://www.dest-unreach.org/socat/doc/socat-openssltunnel.html.

It of course REQUIRES you have a DNS with a local zone resolving the A and PTR (reverse operation giving the name for the IP address locally). I have an unbound server already set for adblocking thanks to a ... bash script of my own I can add it a small zone with both hostname that will be THE only required information to have valid self signed certificate based on the common name (common name = host name).

I could argue that authentication per SSL certificate is strong and my job is done. But, it does not handle Authorization and accounting. What would be nice ... Would be ... groups, login/pass and accounting.

Exactly what /bin/login provides for the authentifcation and accounting and what unix groups/home dir provides :D. No new tools required.

All this is condensed in THIS


The client side



socat READLINE OPENSSL-CONNECT:pubsub.home.:2023,cert=./client.pem,cafile=./server.crt
We politely let socat do the job after we set the DNS virtual address address of pubsub.home (the jail) in the local zone.

The server side



Since the jail is setup we just need a simple rc.d script :
#!/bin/sh
. /etc/rc.subr

name=pubsub
rcvar=pubsub_enable
desc="pubsub server"
start_cmd=pubsub_start
stop_cmd=pubsub_stop
: ${pubsub_enable:=no} 

load_rc_config $name
command=start_cmd
pubsub_start() {
        echo "pubsub started."
        su -m serve -c '/usr/local/bin/socat \
        	OPENSSL-LISTEN:2023,cert=/home/serve/server.pem,cafile=/home/serve/client.crt,fork,reuseaddr \
        	EXEC:"/usr/libexec/getty Pc",ctty,pty,stderr' &
}
pubsub_stop() {
        echo "pubsub stopped."
        killall socat
}
echo hello
run_rc_command "$1"
The socat invocation will listen on port 2023 and use the client certificate in conjonction with its key to secure the connection and fork a new pseudo login tty for each connection.

Hence, given that /etc/bash_profile is :
while [ 1 ]; do
	/home/pubsub/pubsub.sh
	exit
done
You add in the jail
sysrc pubsub_enable="YES" 
And restart the jail and the job is finished.

New account are added with user sharing the same group, /home/pubsub path, and umask at the beginning of the script thanks a sticky bit on the group will ensure that rights are without conflict.

And you can create new users sharing different channels, thus having distinct users possible on a mutualized platform.

All login access will be logged in /var/log/auth.log giving us accounting.

It's basically a pseudo telnet protocol over ssl and a pattern to develop fast when manipulating sockets bores you to death, whereas using stdin/stdout is darn simple.

But ???!!!!

Of course, it's half baked, it lacks the rotation of the channel and reeks of ressource exhaustion, but ... if I would be a company I would devote time later to this, I would probably freeze the pubsub with a SIGHUP trap handler and ask them to kill all their files they follow, sleep, rotate the file, and resume following them (which require an additionnal associative array). Else, we have everything by using a layered design where every layer does it's part of the job : TCP does the transport, SSL the ciphering and one authentication, login+unix groups provides AAA (Authentication, Authorization, Accounting) and the jails a container that can be further hardened thanks to pf.

Security, does not need to be a first thought, security engineers give us very nice tools that can be composed at the best level possible which is the Operating System and its base.

I find the devops hype tiring because abstractions are leaky and each level are coupled in insane ways for the sake of not knowing where your money goes and funnel a lot of money out of both their companies and customers, but we actually can work with 300Mb of memory on small instances of mutualized iron. So I think I proved securing a prototype in a decent way as a second thought can be done fairly easily.

But the joke is not over, a protocol is not over ... until you provide a python library for the protocol. And believe me, it holds in 85 lines of code.

Annexe

No comments: