Topic: SELinux policy for Bitcoin [ALPHA] (Read 3438 times)

When the time comes, I will.

That's great, but why not try and get it merged into upstream?

Announcement:

This project will no longer be maintained separately. SELinux policy for bitcoind is now included with the Bitcoin RPM packages (and policy for bitcoin-qt will follow shortly).

I wonder, if he says attacks are still viable by changing a few pointers, why he's never bothered to share that information so they could be fixed?

The best thing you can do to secure your live OS is to keep it minimal. That means NOT adding features whenever possible. The instant you throw a web server or a bitcoind or any other sort of server on there, then you should reevaluate your choice of grsecurity. One huge advantage of SELinux is that there is a nice out of the box policy (called the Reference Policy) which is maintained by the community and used as a base which all(?) of the major Linux distributions use. There's no "learning mode" because all the intelligence is already there.

The SELinux policy for Bitcoin is intended to be a drop-in policy so that people (merchants, mining pools, exchanges and others) can start using bitcoind as a system service on a new or already existing Linux server and have some reasonable assurance that the wallet.dat is protected. This sort of setup is a requirement, one of many, for medium and large merchants to begin accepting Bitcoin.

Obviously SELinux can't help if an unpatched exploit against SELinux exists (none are currently known to me) but it is also not the only security measure on a typical Linux server. It's also true that grsecurity can't help if an unpatched exploit against grsecurity exists.

So I bet you can guess who was giving me advice I thought that he also told me that these attacks are still viable by changing what pointers your attacking ? I've got to say I thought those exploits were old and pants lol Normally if they are on youtube they and patched that's why I asked. Like I said I'm not really a security guy but was pushed for time and liked the learning feature of grsecurity. When I asked over at the linux IRC channel @ freenode I was abused to the max i was told by those guys SELinux is for real security conscious people and grsecurity was for kiddies Then another guy piped up and I started a bit of a war then logged off lol.

Just thought I'd ask here to get another opinion on all this, you've just confirmed what I thought really. After reading a few more PDF's I'm going to stick with grsecurity I think because it suit's my live os. It seems to me SELinux is more powerful when it comes down to versatility but can be a nightmare to setup. The thing that sold grsecurity to me was the learning mode. An average user can setup leaning mode for a few days and grsecurity and set itself up.

I mean by webscale is that it's normally used for public servers. Sorry to hijack your post bud !!

Eh? Both of those were fixed long ago. Hell, the latter was fixed before the guy even posted the video! And, he also happens to be a bit biased, since he works on grsecurity. A single search turned up numerous grsecurity exploits, all of which I hope have been fixed, so it's not like SELinux is Swiss cheese and grsecurity is Fort Knox. Not sure who you're getting your security information from, but it doesn't sound like a very reliable source.

I also don't know what you mean by "it's webscale"?

Nice !! I just recently implemented grsecurity into linuxcoin. I was going to use SELinux but was put off by lots of friends saying it's webscale ? I'm not sure about this but one of the guys shew me this vid and said this vulnerability and others are still unpatched and out in the wild ?

http://www.youtube.com/watch?v=iN1fdvktRbk&feature=related and http://www.youtube.com/watch?v=KvREwhfQmbc

I'm not really a security guy although I did dabble in bluetooth back in 2008 and wrote some little hacks  

bitcoin-selinux has been updated:

Added proper UPnP support. Removed boolean which was being used as a workaround.

Information and download link are in the top post.

bitcoin-selinux has been updated:

Port 18333 has been added to support bitcoin testnet. (Don't ask how I missed this :\ )
Added permission for bitcoin to send signals to itself, which it seems to do only very occasionally.

Information and download link are in the top post.

Hooray! Now, please lay down and assume the party escort submission position.

bitcoin-selinux has been updated with a bug fix:

Bitcoin was being denied access to read the GNOME/KDE desktop configuration, causing Bitcoin to crash intermittently after sending a transaction. (Though the transaction was not lost.) This has been fixed.

Information and download link are in the top post.

bitcoin-selinux has been updated with a bug fix:

bitcoind was being denied access to the tty, preventing command line usage of bitcoind (e.g. running bitcoind getinfo from a terminal). This has been fixed.

It also has had labeling added for the directory /var/lib/bitcoin, which is LSB/FHS compliant and will be used in a future bitcoind package to store the block chain and wallet.dat when bitcoind is being run as a system service. Doing this will help secure this data against unauthorized access by other programs on the same system.

Information and download link are in the top post.

Yes, this requires a change to Bitcoin. Specifically, the wallet needs to NOT be in the user's home directory, as a user always has access to all of his files (and, as SELinux is currently shipped, it must be accessed via bitcoind started from the init scripts, which doesn't yet exist). But this brings up a couple of other issues, such as access on shared computers, Windows incompatibility, etc.


This is still the case, as far as I know. You can mitigate this somewhat by doing the work in a virtual machine. Whenever I turn off enforcement, I have the audit log rolling in a window so I can see what's going on.

Great, I've been hoping for stuff like this.  My only complaint about SELinux is last time I used it there is no intermediate ground between setenforce 0/1 (i.e., SELinux on/off globally), which means when debugging a new policy you are wide open.  Is this still the case?

Hm?  It shouldn't require any changes to bitcoin.  Just make everything in .bitcoin the bitcoin context and deny everything else access to these files. I also don't see any reason to treat the rest of the files differently.

The wallet encryption already secures access within bitcoin itself.

Watching.

(PS; got a makefile (with list of working dep.s) for a recent bitcoin build on Fedora 15?)

Announcement:

This project will no longer be maintained separately. SELinux policy for bitcoind is now included with the Bitcoin RPM packages (and policy for bitcoin-qt will follow shortly).

I'm doing my part to help secure Bitcoin by developing a SELinux policy module for it. This was developed on Fedora 15 but it should work fine on any recent SELinux-enabled Linux distribution using the targeted policy. To the best of my knowledge, this also includes Red Hat Enterprise, Gentoo Hardened, Debian, and SuSE. There may also be others.

What this does: SELinux provides mandatory access control, permitting users and applications to access only what they absolutely need in order to accomplish given tasks. It prohibits access to resources not in the allowed list, even if a program is exploited to otherwise elevate privileges. This SELinux policy allows Bitcoin to use the files and resources it needs and denies all other access.

This is a WORK IN PROGRESS. I've already identified some things that need to be improved in the policy, and some changes that need to be made to bitcoin itself, before this reaches its full potential as a way to secure wallet.dat from unauthorized access on a live system. I hope you'll subscribe to the thread if you're interested, and if you're REALLY interested, send some bitcoins to 12gVBZMePKdsH4NeegNn6kdJ5XotfPxF76

Donate:
 12gVBZMePKdsH4NeegNn6kdJ5XotfPxF76

Download:
 bitcoin-selinux.tar.gz (release 5)

Install or update:

 When updating, you may see warnings about ports 8332, 8333 and 18333 already being defined in your security policy. These can be safely ignored.

Use:
 Restart Bitcoin or bitcoind after installing (or updating) the policy.

 This policy includes one boolean, bitcoin_use_full_network. Enabling this boolean is required for UPnP to work.
 This boolean has been removed; UPnP support is in the SELinux policy since release 5.

How to test:
 1. Set SELinux to permissive mode:

 2. Run Bitcoin or bitcoind with the policy installed.

 3. Check for AVC denials (replace date and time with the time you started Bitcoin):

 4. This command should return nothing. If you see any output, paste it here.

 5. When finished, set SELinux to enforcing mode:

TODO:
 Separate permissions for bitcoin and bitcoind (bitcoind really doesn't need to access fonts or the X display)
 Special policy for wallet.dat to secure it against unauthorized access (doing this right may require significant changes to the bitcoin client)

History:
 2011-07-19: Release 5
  Added proper UPnP support. Removed boolean which was being used as a workaround.
 2011-07-18: Release 4
  Added port 18333 for Bitcoin testnet
  Added permission for bitcoin to send signals to itself
 2011-07-16: Release 3
  Fixed bitcoin permission to read local GNOME/KDE configuration.
 2011-07-15: Release 2
  Fixed bitcoind permission to read/write to tty.
  Added label for /var/lib/bitcoin for future use.
 2011-07-04: First release.