Just a note -
https://github.com/bitcoin/bitcoin/pull/7609
is my pull request for an RPM spec file.
It has three SELinux files, the way ringingliberty does it with his Fedora RPM.
I'm not sure the SELinux files belong in that pull request but they have to be there currently because no other source for those files exist in the git tree, but SELinux is not something specific to RPM so I think it would be better if appropriate SELinux files either made their way into the source tree to be installed during make install or if there was a contrib directory for SELinux explaining how anyone can use them.
But I'm clearly not the person who should create such a contrib/SELinux because I am not very good with it myself.
Topic: bitcoin and SELinux (Read 746 times)
Thanks, that makes sense actually.
What does rsync do (from one directory to another on the same filesystem)?
I usually just restore the context on the target directory. I guess if you run rsync with -avAX it will preserve context too. Use ls -lZ to check.What does rsync do (from one directory to another on the same filesystem)?
In general it's better to have a proper setup so you can do a relabel anytime as some sort of automagic fix, instead of bothering to preserve contexts.
Some tools might not be able to do this, like zip archives (iirc, tar has an extra option).
And by the way...
Often problems are caused by using mv instead of cp when handling files:
Moving leaves the current context label unchanged, what might cause errors when the context conflicts with the new location.
Copying assigns new context labels to the file, based on the target directory context which gets inherited.
To fix that, either relabel the file, the tree or the entire filesystem.
Often problems are caused by using mv instead of cp when handling files:
Moving leaves the current context label unchanged, what might cause errors when the context conflicts with the new location.
Copying assigns new context labels to the file, based on the target directory context which gets inherited.
To fix that, either relabel the file, the tree or the entire filesystem.
Thanks, that makes sense actually.
What does rsync do (from one directory to another on the same filesystem)?
And by the way...
Often problems are caused by using mv instead of cp when handling files:
Moving leaves the current context label unchanged, what might cause errors when the context conflicts with the new location.
Copying assigns new context labels to the file, based on the target directory context which gets inherited.
To fix that, either relabel the file, the tree or the entire filesystem.
Often problems are caused by using mv instead of cp when handling files:
Moving leaves the current context label unchanged, what might cause errors when the context conflicts with the new location.
Copying assigns new context labels to the file, based on the target directory context which gets inherited.
To fix that, either relabel the file, the tree or the entire filesystem.
Funny, I run SELinux in enforcing mode by default on all servers and even my desktop without any issues. Now and then there is a problem, but that can in 70-80% be solved by toggling a boolean. For a couple of cases I generated custom SE policy modules.
If you go with the standards and defaults, SELinux will rarely be a problem. However if you think you "know it better(tm)", it will kick your shin (as it is supposed to do).
Since you are "knowledgeable enough about SELinux to write such documentation" it shouldn't be any problem at all for you to provide a .te file from which others can generate the .pp
And since you don't care about the data surviving reboots, you could as well just use /dev/shm instead, which is by far faster than any SSD.
All that said, yes, it would be good if the rpm comes with a policy.
If you go with the standards and defaults, SELinux will rarely be a problem. However if you think you "know it better(tm)", it will kick your shin (as it is supposed to do).
Since you are "knowledgeable enough about SELinux to write such documentation" it shouldn't be any problem at all for you to provide a .te file from which others can generate the .pp
And since you don't care about the data surviving reboots, you could as well just use /dev/shm instead, which is by far faster than any SSD.
All that said, yes, it would be good if the rpm comes with a policy.
It works for some people, but for me I kept running into issues - yes they were all solveable but it was like I spending more time researching SELinux than I was spending doing things that were productive. Hence why I stopped using it.
I do have a disability, due to my epilepsy I've hit my head numerous times which causes lapses in memory so I frequently have to re-learn how to do stuff I learned how to do just a few days earlier. Some things that I conceptually get I fly with and it isn't issue, but if the concept doesn't sink it, it ends up being a royal PITA.
Bitcoin, btw, was an epiphany concept that was so beautiful when I learned about it that it just took off in my head - same with DNSSEC - but SELinux not so much.
LaTeX I remember beautifully because I get the concepts, CSS I don't get the concepts and fight with. Most people are the opposite. It's weird like that. But anyway...
Funny, I run SELinux in enforcing mode by default on all servers and even my desktop without any issues. Now and then there is a problem, but that can in 70-80% be solved by toggling a boolean. For a couple of cases I generated custom SE policy modules.
If you go with the standards and defaults, SELinux will rarely be a problem. However if you think you "know it better(tm)", it will kick your shin (as it is supposed to do).
Since you are "knowledgeable enough about SELinux to write such documentation" it shouldn't be any problem at all for you to provide a .te file from which others can generate the .pp
And since you don't care about the data surviving reboots, you could as well just use /dev/shm instead, which is by far faster than any SSD.
All that said, yes, it would be good if the rpm comes with a policy.
If you go with the standards and defaults, SELinux will rarely be a problem. However if you think you "know it better(tm)", it will kick your shin (as it is supposed to do).
Since you are "knowledgeable enough about SELinux to write such documentation" it shouldn't be any problem at all for you to provide a .te file from which others can generate the .pp
And since you don't care about the data surviving reboots, you could as well just use /dev/shm instead, which is by far faster than any SSD.
All that said, yes, it would be good if the rpm comes with a policy.
Hello,
First let me state that as a Linux user since 1998, I am not a fan of SELinux on the personal workstation. Every new release of Fedora I tried running in enforcing mode and ended up disabling it. Every new release in CentOS when I stopped using Fedora the same. With CentOS 7 - the problem came because I was using SSDs for my desktop and laptop and thus using tmpfs for /tmp to reduce the writes to the drive - and apparently SELinux doesn't work very well with /tmp on tmpfs
However if if I was running a server where a lot of financial damage could be done to me or customers from a hack, I would insist upon SELinux because it can in some circumstances save your ass from a zero day exploit that isn't even known to the OS vendor for them to try to patch.
So the bitcoind should have proper SELinux configurations so it can run on servers hardened with SELinux.
There is absolutely no documentation within bitcoin-core source on how to properly set that up.
I am not knowledgeable enough about SELinux to write such documentation but I am hoping a developer here is, because it could be important to safely deploying a node on an SELinux hardened server.
-=-
I do have some basic files that were part of the ringingliberty RPM for bitcoin and appear to have been created from templates, but I must confess I do not know if they are applicable to SELinux outside the Red Hat / Fedora world or if they really are the proper implementation.
Is this the kind of thing where a bounty for proper bitcoin related documented for SELinux could be created and contributed to in order to help motivate a knowledgeable developer to write the documentation? Maybe something for the bitcoin foundation to sponsor?
It does seem to me like it would be important for proper commercial deployment to have a proper guide to deploying bitcoind on a SELinux hardened server.
First let me state that as a Linux user since 1998, I am not a fan of SELinux on the personal workstation. Every new release of Fedora I tried running in enforcing mode and ended up disabling it. Every new release in CentOS when I stopped using Fedora the same. With CentOS 7 - the problem came because I was using SSDs for my desktop and laptop and thus using tmpfs for /tmp to reduce the writes to the drive - and apparently SELinux doesn't work very well with /tmp on tmpfs
However if if I was running a server where a lot of financial damage could be done to me or customers from a hack, I would insist upon SELinux because it can in some circumstances save your ass from a zero day exploit that isn't even known to the OS vendor for them to try to patch.
So the bitcoind should have proper SELinux configurations so it can run on servers hardened with SELinux.
There is absolutely no documentation within bitcoin-core source on how to properly set that up.
I am not knowledgeable enough about SELinux to write such documentation but I am hoping a developer here is, because it could be important to safely deploying a node on an SELinux hardened server.
-=-
I do have some basic files that were part of the ringingliberty RPM for bitcoin and appear to have been created from templates, but I must confess I do not know if they are applicable to SELinux outside the Red Hat / Fedora world or if they really are the proper implementation.
Is this the kind of thing where a bounty for proper bitcoin related documented for SELinux could be created and contributed to in order to help motivate a knowledgeable developer to write the documentation? Maybe something for the bitcoin foundation to sponsor?
It does seem to me like it would be important for proper commercial deployment to have a proper guide to deploying bitcoind on a SELinux hardened server.
Jump to: