I have seen that selinux need to enable auditing support. I want to know the difference between audit and audit2allow, can I just use audit2allow instead of audit?
It seems that no audit support in android code, only audit2allow.
For the audit, I mean the audit package at http://people.redhat.com/sgrubb/audit/.
audit is a daemon, which log denied access (AVC) into /var/log/audit/audit.log
audit2allow is a user-tool to transfer AVP-log into a SELinux-Policy.
examples:
show reason for denied access: cat audit.log | audit2why
create SELinux-Policy foo.pp: cat audit.log | audit2allow -M foo
Related
as I said in the title, I am having trouble updating Nextcloud from version 23.0.0 to 23.0.5.
The system is running on a KVM virtual machine. To upgrade, these are the steps I make:
ssh into the server
cd /var/www/nextcloud
enable maintenance mode: sudo -u www-data php occ maintenance:mode --on
Backing up the machine
Change files ownership so they can be written: chown -R www-data /var/www/nextcloud
Update it: sudo -u www-data php updater/updater.phar
Then, I simply roll back the permissions and disable the maintenance mode
The system updates. However, when I log in and go to the administration overview, I get a warning saying:
Invalid UUIDs of LDAP users or groups have been found. Please review your "Override UUID detection" settings in the Expert part of the LDAP configuration and use "occ ldap:update-uuid" to update them.
When I run the command they say "occ ldap:update-uuid" the console outputs this:
# sudo -u www-data php occ ldap:update-uuid
8/8 [============================] 100%
No record was updated.
For 8 records, the UUID could not be saved to database. Double-check your configuration.
Do you know how to fix this?
Another possibility is getting the UUIDs and replacing them or even removing them if they are not needed. But still, I don't know how to get to them.
I found the solution.
Some LDAP Groups were deleted, and this change did not propagate to NextCloud.
When running sudo -u www-data php occ ldap:update-uuid, you can add --verbose to see what is happening.
In my case, it returned eight groups.
The solution was to open MySQL, select the NextCloud database and then delete the invalid groups in the table oc_ldap_group_mapping. To achieve this, just run:
delete from oc_ldap_group_mapping where directory_uuid like "invalidated_%"
This solution may also apply to LDAP users with invalid UUIDs, but I can't confirm it.
Thanks for your solution!
It works also for oc_ldap_user_mapping with invalid UUIDs.
Select * from oc_ldap_user_mapping where directory_uuid like "invalidated_%"
Delete from oc_ldap_user_mapping where directory_uuid like "invalidated_%"
I'm using ansible to provision my Centos 7 produciton cluster. Unfortunately, execution of below command results with ansible Tiemout and Linux Pluggable Authentication Modules (pam) error conversation failed.
The same ansible command works well, executed against virtual lab mad out of vagrant boxes.
Ansible Command
$ ansible master_server -m yum -a 'name=vim state=installed' -b -K -u lukas -vvvv
123.123.123.123 | FAILED! => {
"msg": "Timeout (7s) waiting for privilege escalation prompt: \u001b[?1h\u001b=\r\r"
}
SSHd Log
# /var/log/secure
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): conversation failed
Aug 26 13:36:19 master_server sudo: pam_unix(sudo:auth): auth could not identify password for [lukas]
I've found the problem. It turned out to be PAM's auth module problem! Let me describe how I got to the solution.
Context:
I set up my machine for debugging - that is I had four terminal windows opened.
1st terminal (local machine): Here, I was executing ansible prduction_server -m yum -a 'name=vim state=installed' -b -K -u username
2nd terminal (production server): Here, I executed journalctl -f (system wide log).
3rd terminal (production server): Here, I executed tail -f /var/log/secure (log for sshd).
4th terminal (production server): Here, I was editing vi /etc/pam.d/sudo file.
Every time, I executed command from 1st terminal I got this errors:
# ansible error - on local machine
Timeout (7s) waiting for privilege escalation prompt error.
# sshd error - on remote machine
pam_unix(sudo:auth): conversation failed
pam_unix(sudo:auth): [username]
I showed my entire setup to my colleague, and he told me that the error had to do something with "PAM". Frankly, It was the first time that I've heard about PAM. So, I had to read this PAM Tutorial.
I figured out, that error relates to auth interface located in /etc/pam.d/sudo module. Diging over the internet, I stambled upon this pam_permit.so module with sufficient controll flag, that fixed my problem!
Solution
Basically, what I added was auth sufficient pam_permit.so line to /etc/pam.d/sudo file. Look at the example below.
$ cat /etc/pam.d/sudo
#%PAM-1.0
# Fixing ssh "auth could not identify password for [username]"
auth sufficient pam_permit.so
# Below is original config
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session include system-auth
Conclusion:
I spent 4 days to arrive to this solution. I stumbled upon over a dozens solutions that did not worked for me, starting from "duplicated sudo password in ansible hosts/config file", "ldap specific configuration" to getting advice from always grumpy system admins!
Note:
Since, I'm not expert in PAM, I'm not aware if this fix affects other aspects of the system, so be cautious over blindly copy pasting this code! However, if you are expert on PAM please share with us alternative solutions or input. Thanks!
Assuming the lukas user is a local account, you should look at how the pam_unix.so module is declared in your system-auth pam file. But more information about the user account and pam configuration is necessary for a specific answer.
While adding auth sufficient pam_permit.so is enough to gain access. Using it in anything but the most insecure test environment would not be recommended. From the pam_permit man page:
pam_permit is a PAM module that always permit access. It does nothing
else.
So adding pam_permit.so as sufficient for authentication in this manner will completely bypass the security for all users.
Found myself in the same situation, tearing my hair out. In my case, hidden toward the end of the sudoers file, there was the line:
%sudo ALL=(ALL:ALL) ALL
This undoes authorizations that come before it. If you're not using the sudo group then this line can safely be deleted.
I had this error since upgrading sudo to version 1.9.4 with pacman. I hadn't noticed that pacman had provided a new sudoers file.
I just needed to merge /etc/sudoers.pacnew.
See here for more details: https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave
I know that this doesn't answer the original question (which pertains to a Centos system), but this is the top Google result for the error message, so I thought I'd leave my solution here in case anyone stumbles across this problem coming from an Arch Linux based operating system.
I got the same error when I tried to restart apache2 with sudo service apache2 restart
When logging into root I was able to see the real error lied with the configuration of apache2. Turned out I removed a site's SSL-Certificate files a few months ago but didn't disable the site in apache2. a2dissite did the trick.
I'm running MariaDB MySQL on a Linux machine. When I attempt to change the password following the documentation, MySQL gives me the following error upon starting:
2017-11-17 9:25:47 139640910462912 [Note] Server socket created on IP: '::'.
ERROR: 1064 You have an error in your SQL syntax; check the manual that corresponds
to your MariaDB server version for the right syntax to use near
'USER 'root'#'localhost' IDENTIFIED BY 'pA$sWord^';' at line 1
2017-11-17 9:25:47 139640910462912 [Note] mysqld: ready for connections.
Version: '10.1.28-MariaDB' socket: '/run/mysqld/mysqld.sock' port: 3306 MariaDB Server
The specific documentation I'm following:
The instructions assume that you will start the MySQL server from the
Unix login account that you normally use for running it. For example,
if you run the server using the mysql login account, you should log in
as mysql before using the instructions. Alternatively, you can log in
as root, but in this case you must start mysqld with the --user=mysql
option. If you start the server as root without using --user=mysql,
the server may create root-owned files in the data directory, such as
log files, and these may cause permission-related problems for future
server startups. If that happens, you will need to either change the
ownership of the files to mysql or remove them.
Log on to your system as the Unix user that the MySQL server runs as
(for example, mysql).
Stop the MySQL server if it is running. Locate the .pid file that
contains the server's process ID. The exact location and name of this
file depend on your distribution, host name, and configuration. Common
locations are /var/lib/mysql/, /var/run/mysqld/, and
/usr/local/mysql/data/. Generally, the file name has an extension of
.pid and begins with either mysqld or your system's host name.
Stop the MySQL server by sending a normal kill (not kill -9) to the
mysqld process. Use the actual path name of the .pid file in the
following command:
shell> kill `cat /mysql-data-directory/host_name.pid`
Use backticks (not forward quotation marks) with the cat command. These cause the
output of cat to be substituted into the kill command.
NOTE: I used top to end the process. I'm certain it is not running.
$ ps aux | grep mysql
user 30201 0.0 0.0 10884 2296 pts/6 S+ 09:43 0:00 grep mysql
Create a text file containing the password-assignment statement on a
single line. Replace the password with the password that you want to
use.
MySQL 5.7.6 and later:
ALTER USER 'root'#'localhost' IDENTIFIED BY 'MyNewPass';
MySQL 5.7.5 and earlier:
SET PASSWORD FOR 'root'#'localhost' = PASSWORD('MyNewPass');
Save the
file. This example assumes that you name the file /home/me/mysql-init.
The file contains the password, so do not save it where it can be read
by other users. If you are not logged in as mysql (the user the server
runs as), make sure that the file has permissions that permit mysql to
read it.
Start the MySQL server with the special --init-file option:
shell> mysqld --init-file=/home/me/mysql-init &
The server executes
the contents of the file named by the --init-file option at startup,
changing the 'root'#'localhost' account password.
Other options may be necessary as well, depending on how you normally
start your server. For example, --defaults-file may be needed before
--init-file.
After the server has started successfully, delete /home/me/mysql-init.
MariaDB Version:
$ sudo pacman -Q | grep mariadb
libmariadbclient 10.1.28-1
mariadb 10.1.28-1
mariadb-clients 10.1.28-1
File /change_root_password.txt:
$ ls -lha /change_root_pwd.txt
-rwxrwxrwx 1 mysql mysql 56 Nov 17 09:24 /change_root_pwd.txt
$ cat /change_root_pwd.txt
ALTER USER 'root'#'localhost' IDENTIFIED BY 'pA$sWord^';
Command used to start mysqld that results in the above mentioned error:
sudo mysqld --user=mysql --init-file=/change_root_pwd.txt
I found this documentation with an alternate SQL query:
If the ALTER USER statement fails to reset the password, try repeating
the procedure using the following statements to modify the user table
directly:
UPDATE mysql.user
SET authentication_string = PASSWORD('MyNewPass'), password_expired = 'N'
WHERE User = 'root' AND Host = 'localhost';
FLUSH PRIVILEGES;
When I try that instead of the ALTER USER query, I get no error, but the password does not get updated.
Perhaps I should have understood the difference between MariaDB and MySQL before asking this question.
I do not know why using that method to reset the root Password does not work, but MariaDB has a simpler way to change the root Password which is documented here:
https://www.linode.com/docs/databases/mariadb/how-to-install-mariadb-on-centos-7
Reset the MariaDB Root Password
If you forget your root MariaDB password, it can be reset.
Stop the current MariaDB server instance, then restart it with an option to not ask for a password:
sudo systemctl stop mariadb
sudo mysqld_safe --skip-grant-tables &
Reconnect to the MariaDB server with the MariaDB root account:
mysql -u root
Use the following commands to reset root’s password. Replace password with a strong password:
use mysql;
update user SET PASSWORD=PASSWORD("password") WHERE USER='root';
flush privileges;
exit
Then restart MariaDB:
sudo systemctl start mariadb
I uses fabric to run a fastcgi_mono service via the command:
sudo('/etc/init.d/fastcgi_mono restart', pty=False)
But when I execute it, it gives me this error:
[52.192.204.174] run: sudo /etc/init.d/fastcgi_mono restart
[52.192.204.174] out: sudo: sorry, you must have a tty to run sudo
[52.192.204.174] out:
Warning: run() received nonzero return code 1 while executing 'sudo /etc/init.d/fastcgi_mono restart'!
how do I solve this issue? Please help.
The way i solve this is, I dont know if there is a better way but it makes sense in my head: I have two users set up in my fabfile.py, ubuntu (which has sudo privileges) and www-data (which does not have any real rights, only can add/delete directories in its "space" (/server/*)). I always establish connections using ubuntu that way i can use sudo() when ever i need to. When ever i need to do something at the application level, what i call def deploy() i connect using the application user, so i do something like:
#settings(user='www-data')
def deploy():
run('whoami') # will say www-data
or if i need to do some kind of sudo() inside my deploy() i'll do:
def deploy():
sudo('whoami') # will say ubuntu/root
with settings(user='www-data'):
run('whoami') # will say www-data
... more code here
so recap:
Connect using a user that has sudo access
Change the user to a higher level user if need be later
Yes I found the answer. For Amazon instances, you need to disable requiretty
comment('/etc/sudoers', 'Defaults requiretty', use_sudo=True)
I am trying to run python script in Apache 2.x with mod_python. I edited httpd.conf with publisher
LoadModule python_module /usr/local/apache2/modules/mod_python.so
<Directory /usr/local/apache2/htdocs/mod_python>
SetHandler mod_python
PythonHandler mod_python.publisher
PythonDebug On
I am trying to add a rule in firewall using python script which require root privilege. it's asking for root privilege ? Please somebody help.
#!/usr/local/bin/python
#from mod_python import apache
import sys
import errno
import pf
def index(req):
filter = pf.PacketFilter()
try:
# Enable packet filtering
filter.enable()
print "pf is enabled"
return "pf is enabled"
except IOError, (err, msg):
if err == errno.EACCES:
#sys.exit("Permission denied: are you root?")
return ("Permission denied: are you root?")
elif err == errno.ENOTTY:
#sys.exit("ioctl not supported by the device: is the pf device correct?")
return ("ioctl not supported by the device: is the pf device correct?")
this is python script which i want to execute though apache at openBSD. it uses mod_python.
Please post your python script somewhere and give us the link.
How is your python script trying to communicate with pf? through pfctl? lets say you are tryng to add an IP to a table
pfctl -t thetable -T add x.x.x.x
Find out which user runs apache
ps aux | grep apache
Then you must edit /etc/sudoers to have that user be able to run the pfctl command without a password. So lets say that you run apache as www. place the following in sudoers :
www ALL=(ALL:ALL) NOPASSWD: /sbin/pfctl
Finally in the python script (lets say you call the external command with subprocess)
from subprocess import call
call(["sudo","pfctl","-T","theTable","-t","add", "x.x.x.x"])
But please keep in mind that the whole scheme is really a bad idea and you shouldn't do it that way. get rid of the python script if you can and run the bundled apache 1.3 which is privseped and audited. Run the webserver in a chroot. Never expose the control of your firewall to user input specially when this comes over the web. I am sure that if you elaborate on what you want to do , we could find a much more efficient and secure setup.
You cannot run Python scripts under mod_python as the root user. This is because Apache will always drop privileges to an untrusted user. The only way to get around it would be to recompile Apache from source code and define a magic preprocessor macro which enables the security hole which allows Apache worker processes to run as root.
In summary, don't do it, it is dangerous.
Also be aware the mod_python is no longer maintained or developed and it is questionable as to whether you should use it in the first place.