Docker's default container AppArmor profile contains a single "file" clause, without any additional information:
file,
What does this really mean, does this clause grant full access to any file? I've checked with AppArmor's apparmor.d(5) man page, but it does not mention this case explicitly, contrary to, say:
# Allow all PTrace access
ptrace,
Months later I finally stumbled upon an explanation, not from the AppArmor project itself, but from OpenSUSE, in their "Security and Hardening Guide", chapter "Profile Components and Syntax", heading "30.7.70 Optional allow and file Rules":
The following rule grants access to all files:
file,
Related
I'm following instructions here and it says that I will find a bitcoin.conf file Windows: %APPDATA%\Bitcoin\ and
To use bitcoind and bitcoin-cli, you will need to add a RPC password to your bitcoin.conf file. Both programs will read from the same file if both run on the same system as the same user, so any long random password will work: rpcpassword=change_this_to_a_long_random_password
However When I navigate to %APPDATA%\Bitcoin\ I don't see a bitcoin.conf file.
So What do I do? Do I add a bitcoin.conf file? There is a bitcoin-conf.md file in doc in my bitcoin install directory so maybe somthing todo with that? I really don't know. Thanks for pointing me in the right direction.
That guide does not take into account the fact that you do not have to add any RPC user or password to your configuration file for the past some years.
Bitcoind will generate a cookie that allows the CLI (command line interface) to communicate with the Bitcoin daemon using RPC without the user having had to give it a single thought.
That is a developers' guide, so developers may have more complex requirements that are solved if they specify their own RPC authentication settings, such as running multiple wallets, or possibly exchange software that communicates with the wallet or multiple wallets.
bitcoin.conf being optional, it is not by default created, and is not needed for ordinary usage, only becoming necessary when the user or developer has particular, non-default settings to set.
The possible settings can be found by the help command bitcoind -help and lists a number of command line parameters (beginning with a dash or hyphen) that can be typed or pasted after bitcoind on the command line, but can be put in a text file named bitcoin.conf without the minus sign before the command. For example: -connect=IPAddress becomes simply connect=IPAddress in the conf file.
For creating suitable rpcauth (username and hashed password), and rpcuser and rpcpassword values, I've found some resources such as https://github.com/jlopp/bitcoin-core-rpc-auth-generator
Rather than serving JLopp's RPC auth generator locally you can simply copy from, or use a Python script found in the Bitcoin repository under the folder named "share", you will see a folder called rpcauth which contains the rpcauth.py script and a small explanatory file called README.md.
You have to create this file and put a single line rpcpassword=<your_password> in it.
bitcoin-conf.md contains documentation for this btcoin.conf and particularily states:
The configuration file is not automatically created; you can create it using your favorite text editor.
Recommended reading this doc. It may help you to facilitate running your node.
I am running into a problem with labeling. In order to lock down access to a file /etc/avahi/avahi-daemon.conf I decided to label it as a part of the avahi_t domain.
I am working on an embedded system. When I boot up the system from a version update, the file system is relabeled with the .autorelabel flag set.
Unfortunately the file /etc/avahi/avahi-daemon.conf remains in the unlabeled_t type. Due to the label being wrong, it is unable to read the file and avahi fails to initialize properly with an avc read denied on an unlabeled_t file. I want to have the label correctly set and not modify policy to read an unlabeled file. I also want it to be protected so the configuration can not be modified.
I have properly labeled it in the .fc file with the following:
/etc/avahi/avahi-daemon.conf -- gen_context(system_u:object_r:avahi_t,s0)
When I try a restorecon on the file system it attempts to relabel the file but is blocked by SELinux with a relabelto avc violation. Similarly changing it with chcon -t fails to change it. I do not wish to open relabelto up on an embedded system as it can then be relabeled and take down the avahi initialization. If I take out the SD card, and relabel the file on a different system. And place it back into the target system it is properly labeled. And avahi operates correctly. So I am certain that the labeling is causing the problem.
In looking in the reference policy an init_daemon_domain(avahi_t,avahi_exec_t) is being performed.
In looking at the documentation for init_daemon_domain() it states the following:
"The types will be made usable as a domain and file, making calls to domain_type() and files_type() redundant."
This is unusual in that if I add files_type(avahi_t) to the .te file, it properly labels after version update.
I am really wanting to know more information about this, and unfortunately my searches on the internet have been less than fruitful in this regard.
Is the documentation for SELinux wrong? Am I missing something about init_daemon_domain() in that it only works with processes and not files?
Or is the files_type(avahi_t) truly needed?
I know this comes off as a trivial issue since there is a path to where it is working. However I am hoping to get an explanation as to why files_type(avahi_t) is necessary?
Thanks
I want to be able to block or allow users based on the result of an external script using OpenSSH. I see that libssh has support for callbacks, but after reading the OpenSSH man pages I cannot find anywhere that this functionality is handed to the user.
For example, I'd like to be able to maintain either a file or even an API that contains a username blacklist or whitelist, and have OpenSSH consult these lists during the authentication process.
Ideas I've had so far, and why they are insufficient:
Make use of sshd_config: AllowUsers. This is a start, but since it does not read from a file, it is not dynamic. The configuration file would need to be changed every time and the service restarted. Additionally, modifying the config file from a script is dangerous and terrible.
Make use of sshd_config: AuthorizedKeysCommand. Unfortunately, while this does allow you to specify a script and grant access based on the result, it does not allow denial of access. If the script returns nothing, sshd continues to try other methods of authentication.
Recompile OpenSSH with an addition that implements the libssh callbacks. I'd rather not do this for obvious reasons of maintainability.
Is there another method that I have missed while reading the documentation?
For 2. you could limit authentication to publickey with AuthenticationMethods.
Another option is to use PAM and implement your own PAM authz module.
Option 2 is sufficient if you disable checking authorized_keys:
sshd_config:
AuthorizedKeysCommand /etc/ssh/my-custom-command
AuthorizedKeysUser nobody
AuthorizedKeysFile none
my-custom-command:
# $1 is user, as passed from sshd
#psuedo code:
if $1 is in whitelist:
cat /home/$1/.ssh/authorized_keys
exit 0
else
exit 1
I have installed OEM 13c and deployed a couple of agents and want to test out the Log File Monitoring utility. I have enabled it and added a log file to monitor.
When I go and test it out, it does not show any alerts when they are put into the Log File. On the agent server, I have tailed the file and see the messages coming into the log file.
Does anyone have experience adding log files to OEM? I could have configured it wrong. Or is there any troubleshooting steps that I can follow to see if the server is even contacting the agent for reading the log file. Status of the agent is good with no incidents.
Without access to the system, it would be difficult to tell you the exact cause of this issue. However, I can list a few potential causes of this issue that I have experienced personally:
Permissions. The Oracle Enterprise Manager Agent is very convoluted when it comes to system permissions within a remote server. The agent can be owned and run as any number of users but during metric evaluation, may also need sudo or pam-authentication permissions to access certain entities on the server. Depending on the authentication profiles on that server, this could be the cause of your issue. There are ways to grant the agent access through the PAM stack if that is necessary.
Syntax. The wildcard syntax in the OEM GUI can be a little confusing as well. I would play with the wildcard elements a bit on the "String" component to ensure that it isn't as simple as adding wildcards to the beginning and end of the string. Without diving into the binaries of the agent plugins, it is difficult to assess exactly how the agent is evaluating this particular metric
One suggestion I would have is to go through the agent commands. There are specific commands you can run to manually force an agent to evaluate a particular metric for a particular target. This can allow you to manually trigger the metric collection locally on the server and evaluate what exactly is being performed at the agent level.
On the system I was running (12c) the command was as follows:
emctl control agent runCollection <hostname>:host host_storage
I have a NetApp filer, with a CIFS export. The permissions have been locked down on it, to a point where it's no longer accessible.
I need to reset the permissions on this - I've figured out I can probably do this by changing the qtree to Unix security mode and back again (provided I'm prepared to unexport the share temporarily).
However, I think I should be able to use the fsecurity command to do this. There's just one problem - the manpage example refers to 'applying ACLs from a config file':
https://library.netapp.com/ecmdocs/ECMP1196890/html/man1/na_fsecurity_apply.1.html
But what it doesn't do, is give me an example of what a 'security definition file' actually looks like.
Is anyone able to give me an example? Resetting a directory structure to Everyone/Full Control is sufficient for my needs, as re-applying permissions isn't a problem.
Create a conf file containing the following:
cb56f6f4
1,0,"/vol/vol_name/qtree_name/subdir",0,"D:P(A;CIOI;0x1f01ff;;;Everyone)"
Save it on your filer somewhere (example in manpage is /etc/security.conf).
Run:
fsecurity show /vol/vol_name/qtree_name/subdir
fsecurity apply /etc/security.conf
fsecurity show /vol/vol_name/qtree_name/subdir
This will set Everyone / Full Control: inheritable. Which is a massive security hole, so you should now IMMEDIATELY go and fix the permissions on that directory structure to something a little more sensible.
You can get create more detailed ACLs using the 'secedit' utility, available from NetApp's support site. But this one did what I needed it to.