There are Fedora 25 and apache on our server.
I want to do so that the php script on our web site can change crontab settings.
I created the following test php script:
<?php
system("echo '*/2 * * * * date > /var/www/logs/testlog.txt' | crontab - 2>&1");
But it did not work. I got the message:
/var/spool/cron/#tmp.mh203-95.XXXXG0KrFF: Permission denied
I looked at output of sealert -a /var/log/audit/audit.log
and found:
SELinux is preventing crontab from write access on the directory /var/spool/cron.
Okay. It sounds like apache is not allowed the write access to /var/spool/cron because that directory has not the httpd_sys_rw_content_t label.
So I executed the command:
chcon -v -R -t httpd_sys_rw_content_t /var/spool/cron
My php script begun to work. The crontab -l command gave normal output.
But the new problem appeared. :( The cron tasks was not executed.
In the /var/log/cron I saw the error:
Mar 23 18:05:01 mh203-95 crond[1653]: (apache) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:httpd_sys_rw_content_t:s0 (/var/spool/cron/apache)
Mar 23 18:05:01 mh203-95 crond[1653]: (apache) FAILED (loading cron table)
After many time of research... I found that the /var/spool/cron must have the user_cron_spool_t label. So I executed: chcon -v -R -t user_cron_spool_t /var/spool/cron.
The cron tasks begun to works. But my php script did not work again. The same problem as at the beginning.
sealert suggested the commands like:
ausearch -c 'crontab' --raw | audit2allow -M my-crontab
semodule -X 300 -i my-crontab.pp
But it did not help.
What am I missing?
How to solve the problem?
Can I somehow combine two labels user_cron_spool_t and httpd_sys_rw_content_t for /var/spool/cron directory?
I had solved the problem.
The reason was in this: sealert generates the same politic name my-crontab in all suggested commands. The new politic overwrote the old.
It is just needed to change this name slightly.
So i executed:
ausearch -c 'crontab' --raw | audit2allow -M my-crontab
semodule -X 300 -i my-crontab.pp
ausearch -c 'crontab' --raw | audit2allow -M my-crontab2
semodule -X 300 -i my-crontab2.pp
ausearch -c 'crontab' --raw | audit2allow -M my-crontab3
semodule -X 300 -i my-crontab3.pp
...
Before every ausearch ... I executed:
echo -n "" > /var/log/audit/audit.log
My php script.
sealert -a /var/log/audit/audit.log
Related
Is there any way to watch php activities online? I am looking for something like apache logs that I can I run tail -f /var/log/httpd/access.log in the terminal and then open the URL in a browser and see what apache prints.
So, I am seeking for similar thing for php web pages. The php is 7.2
UPDATE1:
Trying to watch system log with tail -f /var/log/messages, I get many messages similar to this in the terminal when the page is reloaded from browser.
python: SELinux is preventing /usr/sbin/httpd from write access on the directory /var/www/html/ow_userfiles/plugins/admin.#012#012***** Plugin httpd_write_content (92.2 confidence) suggests ***************#012#012If you want to allow httpd to have write access on the admin directory#012Then you need to change the label on '/var/www/html/ow_userfiles/plugins/admin'#012Do#012# semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/ow_userfiles/plugins/admin'#012# restorecon -v '/var/www/html/ow_userfiles/plugins/admin'#012#012***** Plugin catchall_boolean (7.83 confidence) suggests ******************#012#012If you want to allow httpd to unified#012Then you must tell SELinux about this by enabling the 'httpd_unified' boolean.#012#012Do#012setsebool -P httpd_unified 1#012#012***** Plugin catchall (1.41 confidence) suggests **************************#012#012If you believe that httpd should be allowed write access on the admin directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'httpd' --raw | audit2allow -M my-httpd#012# semodule -i my-httpd.pp#012
It is an ugly message! I think I have to run semanage fcontext -a -t with some paths. Not sure which paths exactly!
UPDATE2:
A more clear log is available with the following command
[root#localhost html]# sealert -l e254cabb-7005-4a3c-8f91-8620c924c5e0
SELinux is preventing /usr/sbin/httpd from write access on the file /var/www/html/ow_includes/config.php.
***** Plugin httpd_write_content (92.2 confidence) suggests ***************
If you want to allow httpd to have write access on the config.php file
Then you need to change the label on '/var/www/html/ow_includes/config.php'
Do
# semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/ow_includes/config.php'
# restorecon -v '/var/www/html/ow_includes/config.php'
***** Plugin catchall_boolean (7.83 confidence) suggests ******************
If you want to allow httpd to unified
Then you must tell SELinux about this by enabling the 'httpd_unified' boolean.
Do
setsebool -P httpd_unified 1
***** Plugin catchall (1.41 confidence) suggests **************************
If you believe that httpd should be allowed write access on the config.php file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'httpd' --raw | audit2allow -M my-httpd
# semodule -i my-httpd.pp
Additional Information:
Source Context system_u:system_r:httpd_t:s0
Target Context unconfined_u:object_r:httpd_sys_content_t:s0
Target Objects /var/www/html/ow_includes/config.php [ file ]
Source httpd
Source Path /usr/sbin/httpd
Port <Unknown>
Host localhost.localdomain
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-192.el7_5.6.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name localhost.localdomain
Platform Linux localhost.localdomain
3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14
21:49:04 UTC 2018 x86_64 x86_64
Alert Count 108
First Seen 2018-09-02 16:51:25 +0430
Last Seen 2018-09-02 23:00:19 +0430
Local ID e254cabb-7005-4a3c-8f91-8620c924c5e0
Raw Audit Messages
type=AVC msg=audit(1535913019.143:9913): avc: denied { write } for pid=5121 comm="httpd" name="config.php" dev="dm-0" ino=18219610 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file
Hash: httpd,httpd_t,httpd_sys_content_t,file,write
This is an SELinux issue, as is apparent by the logs messages...
SELinux is preventing /usr/sbin/httpd from write access on the directory /var/www/html/ow_userfiles/plugins/admin.#012#012*****
...
If you want to allow httpd to have write access on the admin directory
Then you need to change the label on '/var/www/html/ow_userfiles/plugins/admin'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/ow_userfiles/plugins/admin'
restorecon -v '/var/www/html/ow_userfiles/plugins/admin'
Start with the first error, do exactly as it states.. and see if that resolves e others.
If other errors still exist after running these commands, follow the res of the instructions in the very clear error message you were presented.
Here is a php « tail » from my notes to play around.
It is similar to tail -n 5 access.log
This will answer the last 5 lines of access.log.
To make it acting like tail -f, just use a loop.
$check = "access.log";
$end = "5";
$fp= fopen($check, "r");
$count=0;
while($line = fgetss($fp))
$count++;
// echo "Total lines ".$count.PHP_EOL;
fclose($fp);
$start = $count - $end;
$file = new SplFileObject($check);
$file->seek($start);
for($i = 0; !$file->eof() && $i < $end; $i++) {
echo $file->current();
$file->next();
}
It is also very fast, the whole file isn't taken in memory, just like tail.
SplFileObject
I have the shell script "test.sh":
#!/system/bin/sh
PID=$(ps | grep logcat | grep root |grep -v grep | awk '{print $2}')
echo "Using awk: $PID"
PID=$(ps | grep logcat | grep root |grep -v grep | cut -d " " -f 7 )
echo "Using cut: $PID"
When I run the script from PHP:
exec("su -c sh /path/to/my/script/test.sh");
I got this output:
Using awk:
Using cut: 6512
So "cut" command is work but "awk" command doesn't when I run the script from PHP, but when I run it from terminal:
# sh test.sh
I can get both awk and cut work fine! This how look like the output of "ps":
USER PID PPID VSIZE RSS WCHAN PC NAME
root 6512 5115 3044 1108 poll_sched b6e4bb0c S logcat
Do I missed something?
You should learn how to debug first
You said
So "cut" command is work but "awk" command doesn't when I run the
script from PHP, but when I run it from terminal:
I wonder how ?
actually throws error like below, in CLI
$ php -r 'exec("su -c sh /path/to/my/script/test.sh");'
su: user /path/to/my/script/test.sh does not exist
You first need below syntax while debugging code
// basic : stdin (0) stdout (1) stderr (2)
exec('your_command 2>&1', $output, $return_status);
// to see the response from your command
// su: user /path/to/my/script/test.sh does not exist
print_r($output);
Remember :
su gives you root permissions but it does not change the PATH variable and current working directory.
The operating system assumes that, in the absence of a username, the
user wants to change to a root session, and thus the user is prompted
for the root password
[akshay#localhost Desktop]$ su
Password:
[root#localhost Desktop]# pwd
/home/akshay/Desktop
[root#localhost Desktop]# exit
exit
[akshay#localhost Desktop]$ su -
Password:
[root#localhost ~]# pwd
/root
Solution:
You should allow executing your script without password prompt ( don't use su use sudo )
To allow apache user to execute your script and some commands you may make entry like below in /etc/sudoers
# which awk => give you awk path
# same use in your script also, or else set path variable
www-data ALL=NOPASSWD: /path/to/my/script/test.sh, /bin/cut, /usr/bin/awk
So it becomes :
// assuming your script is executable
exec("sudo /path/to/my/script/test.sh 2>&1", $output);
print_r($output);
I'm trying to start a bash script later in PHP so I allowed it in visudo.
www-data ALL = (root) NOPASSWD: /sbin/iptables
www-data ALL = (root) NOPASSWD: /usr/bin/at
The script removeuserIP is just doing sudo iptables ... and is working:
#!/bin/bash
sudo iptables -t nat -D PREROUTING -s $1 -j ACCEPT;
sudo iptables -D FORWARD -s $1 -j ACCEPT;
and in the PHP code, I put this line:
$msg=exec("echo /var/www/scripts/removeuserIP $ipaddress | at now + 1 minutes");
but the issue is it's starting the script right now. I checked in /log/var/auth.log and indeed, it's starting the command right now.
I tried it in a terminal directly and there was no issue, it is starting later (with an argument of course):
echo /var/www/scripts/removeuserIP $ipaddress | at now + 1 minutes
I also tried to do it like this in a terminal but this one is not working too because it doesn't understand there is an argument for the file:
sudo at now +1 minutes -f /var/www/scripts/removeuserIP 172.24.1.115
I really don't understand why it is starting right now even if it should start 1 minute later and not now.
Would it be acceptable to put a time delay in removeuserIP script?
#!/bin/bash
sleep 1m
sudo iptables -t nat -D PREROUTING -s $1 -j ACCEPT;
sudo iptables -D FORWARD -s $1 -j ACCEPT;
Solution: Finally, after checking /var/log/apache2/error.log, I saw that it doesn't have the permission to use at.
In fact you have to go /etc/at.deny and remove the line www-date with at. There is probably a security reason for why it's forbidden by default and a better way to do this, but at least it's working.
I have a nodejs script named script.js.
var util = require('util');
var net = require("net");
process.on("uncaughtException", function(e) {
console.log(e);
});
var proxyPort = "40000";
var serviceHost = "1.2.3.4";
var servicePort = "50000";
net.createServer(function (proxySocket) {
var connected = false;
var buffers = new Array();
var serviceSocket = new net.Socket();
serviceSocket.connect(parseInt(servicePort), serviceHost);
serviceSocket.pipe(proxySocket).pipe(serviceSocket);
proxySocket.on("error", function (e) {
serviceSocket.end();
});
serviceSocket.on("error", function (e) {
console.log("Could not connect to service at host "
+ serviceHost + ', port ' + servicePort);
proxySocket.end();
});
proxySocket.on("close", function(had_error) {
serviceSocket.end();
});
serviceSocket.on("close", function(had_error) {
proxySocket.end();
});
}).listen(proxyPort);
I am runing it normally like nodejs script.js, but now i want to include forever or pm2 functionalities as well. When i am root everything works smootly:
chmod -R 777 /home/nodejs/forever/;
-- give rights
watch -n 0.1 'ps ax | grep forever | grep -v grep'
-- watch forwarders (where i see if a forever is opened)
/usr/local/bin/forever -d -v --pidFile "/home/nodejs/forever/file.pid" --uid 'file' -p '/home/nodejs/forever/' -l '/home/nodejs/forever/file.log' -o '/home/nodejs/forever/file.log' -e '/home/nodejs/forever/file.log' -a start /etc/dynamic_ip/nodejs/proxy.js 41789 1.2.3.4:44481 414 file
-- open with forever
forever list
-- it is there, i can see it
forever stopall
-- kill them all
The problem is when i want to run the script from a PHP script with the system or exec functions :
sudo -u www-data /usr/local/bin/forever -d -v --pidFile "/home/nodejs/forever/file.pid" --uid 'file' -p '/home/nodejs/forever/' -l '/home/nodejs/forever/file.log' -o '/home/nodejs/forever/file.log' -e '/home/nodejs/forever/file.log' -a start /etc/dynamic_ip/nodejs/proxy.js 41789 1.2.3.4:44481 414 file
-- open as www-data (or i can do this just by accessing `http://1.2.3.4/test.php`, it is the same thing)
forever list
-- see if it is there, and it is not (i see it in watch)
forever stopall
-- says no forever is opened
kill PID_ID
-- the only way is to kill it by pid ... and on another server all of this works very well, can create and kill forevers from a php script when accessing it from web ... not know why
-- everything is in /etc/sudoers including /usr/local/bin/forever
Why is that? How can i solve this?
I also made some trick, created a user 'forever2', i created a script.sh with this content :
sudo su forever2 user123; /usr/local/bin/forever -d -v --pidFile "/home/nodejs/forever/file.pid" --uid 'file' -p '/home/nodejs/forever/' -l '/home/nodejs/forever/file.log' -o '/home/nodejs/forever/file.log' -e '/home/nodejs/forever/file.log' -a start /etc/dynamic_ip/nodejs/proxy.js 41789 1.2.3.4:44481 414 file;
where user123 is not existent, is just a trick to exit the shell after execution. The script works, runs forever, i can close all forevers with the command forever stopall from root. When i try the same thing running the http://1.2.3.4/test.php or as www-data user i cannot close it from root or www-data, so not even this works.
I tried from Ubuntu 14.04.3 LTS, Ubuntu 14.04 LTS , Debian GNU/Linux 8 ... still the same thing.
Any ideeas?
Thanks.
If you are starting the process from within Apache or the web-server you are already as the www-data user, so doing a sudo su to the user context you already have is likely not necessary.
When you start this forever task you may also be required to shut the terminals/inputs and directly send to background. Something like this:
// Assemble command
$cmd = '/usr/bin/forever';
$cmd.= ' -d -v --pidfile /tmp/my.pid'; // add other options
$cmd.= ' start';
$cmd.= ' /etc/dynamic_ip/nodejs/proxy.js';
// "magic" to get details
$cmd.= ' 2>&1 1>/tmp/output.log'; // Route STDERR to STDOUT; STDOUT to file
$cmd.= ' &'; // Send whole task to background.
system($cmd);
Now, there won't be any output here but you should have something in /tmp/output.log which could show why forever failed, or the script crashed.
If you've been running the script sometimes as root, then trying the same command as www-data you may also be running into a permissions on one or more files/directories created from the execution as root which now conflict when running as www-data.
This is part of PHP security you say you're running it from a php script and your not your running it from Apache via a php script.
PHP web scripts should not have root access as such they run under the same permissions as Apache user www-data.
There are ways to prevent php running as root but run a task as root but it's a little hacky and I'm not going to share the code but I will explain so you can look into it. here is where to start
http://php.net/manual/en/function.proc-open.php
With a Proccess like this you can then execute a proc. Like your script.js via nodeJS using SUDO and then read stdOut and stdErr wait for password request then provide it by writing to stdIn for that process.
Don't forget in doing this the user www-data has to have a password and be in the sudoers list
Per the OPs Comment
Due to the way SUDO works the PATH does not appear to contain the path to the node executables npm, node so your best of building a .sh (bash script) and using sudo to run that.
You still need to monitor this process as it will still ask for a password
#!/bin/bash
sudo -u ec2-user -i
# change this to the path you want to run from
cd ~
/usr/local/bin/pm2 -v
Ok, so I have a ssh connection open to a remote server. I'm running a tail on the logs and if an ID shows up in the logs I need to do an insert into the database.
So I have my ssh tail working and I have it piping into my grep function which is giving me the IDs I need. The next step is that as those IDs are found it needs to immediately kick off a php script.
What I thought it would look like is:
ssh -t <user>#<host> "tail -f /APP/logs/foo.log" | grep -oh "'[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'" | php myscript.php <grep result>
And yes my regex is horrible, wanted to use [0-9]{8}, but what I have gets the job done.
Any suggestions? Tried looking at -exec, awk, or any other tool. I could write the result to its own file and then read the new file, but that doesn't catch the streaming ids.
-=-=-=-=-EDIT-=-=-=-=-=-
So here is what I'm using:
ssh -t <user>#<host> "tail -f /APP/logs/foo.log" |grep "^javax.ejb.ObjectNotFoundException" |awk '/[0-9]/ { system("php myscript.php "$6) }'
And if I use tail -l #lines it works, or if after a while I ctrl-c, it then works. The behavior I wanted though was to as the tail got a bad ID to kick off the script to fix the bad ID. Not wait until an EOF or some tail buffer...
I'm having similar problem. There's something funny with tail -f and grep -o combination when ssh.
So on local server, if you do
tail -f myfile.log |grep -o keyword
It grep just fine.
But if you do it from remote server....
ssh user#server 'tail -f myfile.log |grep -o keyword'
doesn't work
But if you remove -f from tail or -o from grep, work just fine... weird :-/