hook the execve system call what is the const __user parmter and how can i extract the file name
hi i hooked the execve system call and when i told it to print log each time that process been execute it worked fine but when i wanted to print the file name parameter it crashed my computer , how can i find the file exe path of the process or the binary code of it
this is my code
``asmlinkage long our_execl( const char __user* filename, const char __user* const __user* argv,const char __user* const __user* envp )
{`
printk(filename); return orignal_execl( filename, argv, envp );
}
`
Answers
-
Im a bit to tired to fully understand your question (5.30 am and a long day..).
But as i understand it you wish to log all usage of the execve and execve_at system calls which the audit framework is quite good at (it's getting it to shut up that's tricky, but it sort of forces you..)If creating a process, use a simple systemd service and take advantage of the features in systemd.exec and systemd.unit (man pages), and it will, especially combined with audit log any start/stop of the process.
Otherwise, how about using the Audit framework and specify a rule to listen for system calls execve and execve_at?
A rule syntax to use (for 32bit ABI calls and 64) to build upon (this will cause massive spam):
-a always,exit -F arch=b32 -S execve -S execve_at -k EXECVE_USAGE
-a always,exit -F arch=b64 -S execve -S execve_at -k EXECVE_USAGE-k EXECVE_USAGE can be replaced by any name you wish audit to label the rule with (k = key, EXECVE_USAGE is the name/key i gave in the example).
A more useful (and less spam the hell out of the system) approach would be to add -F success=no and -F uid=0 -F euid 0 to log only failed attempts (even though a better example is below but in order to show the -F field=value concept), by the root user and the auid (real user who used for example sudo) and the execution paths will be reported, a lot.
Logging all use of these syscalls will fill your logs EXTREMELY fast, they are used for any service activation and much else and i tried going down that route once, but perhaps someone can improve upon it...Another way to go is:
-a always,exit -F arch=b32 -S execve -S execve_at -F exit=-EACCES -k EXECVE_FAIL
-a always,exit -F arch=b32 -S execve -S execve_at -F exit=-EPERM -k EXECVE_FAIL
-a always,exit -F arch=b64 -S execve -S execve_at -F exit=-EACCES -k EXECVE_FAIL
-a always,exit -F arch=b64 -S execve -S execve_at -F exit=-EPERM -k EXECVE_FAILThis will log any attempt at using the execve syscalls, if they fail due to permission or access failure which may imply an intrusion attempt.
I would suggest adding excluding rules for cwd , Proctitle, sockaddress and seccomp messages as well as some others to avoid logspam (see man pages on audit.rules for information and it also contains loads of examples as do google)
-a exclude,always -F msgtype=CWD
-a exclude,always -F msgtype=SECCOMP
-a always,exclude -F msgtype=PROCTITLE
-a always,exclude -F msgtype=SOCKADDRExlude these as well, the goal of audit it to catch relevant data, not all of it (if that is the case, leave the rules blank and until the SSD fails everything is logged).
-a always,exclude -F msgtype=TIME_ADJNTPVAL
-a always,exclude -F msgtype=TIME_INJOFFSETTime for bed..
0
Categories
- 9.9K All Categories
- 29 LFX Mentorship
- 82 LFX Mentorship: Linux Kernel
- 469 Linux Foundation Boot Camps
- 267 Cloud Engineer Boot Camp
- 95 Advanced Cloud Engineer Boot Camp
- 43 DevOps Engineer Boot Camp
- 31 Cloud Native Developer Boot Camp
- 1 Express Training Courses
- 1 Express Courses - Discussion Forum
- 1.6K Training Courses
- 18 LFC110 Class Forum
- 4 LFC131 Class Forum
- 19 LFD102 Class Forum
- 133 LFD103 Class Forum
- 9 LFD121 Class Forum
- 60 LFD201 Class Forum
- LFD210 Class Forum
- 1 LFD213 Class Forum - Discontinued
- 128 LFD232 Class Forum
- 23 LFD254 Class Forum
- 545 LFD259 Class Forum
- 100 LFD272 Class Forum
- 1 LFD272-JP クラス フォーラム
- 1 LFS145 Class Forum
- 20 LFS200 Class Forum
- 739 LFS201 Class Forum
- 1 LFS201-JP クラス フォーラム
- 1 LFS203 Class Forum
- 37 LFS207 Class Forum
- 296 LFS211 Class Forum
- 53 LFS216 Class Forum
- 45 LFS241 Class Forum
- 40 LFS242 Class Forum
- 33 LFS243 Class Forum
- 10 LFS244 Class Forum
- 27 LFS250 Class Forum
- 1 LFS250-JP クラス フォーラム
- 131 LFS253 Class Forum
- 967 LFS258 Class Forum
- 10 LFS258-JP クラス フォーラム
- 85 LFS260 Class Forum
- 124 LFS261 Class Forum
- 29 LFS262 Class Forum
- 78 LFS263 Class Forum
- 15 LFS264 Class Forum
- 10 LFS266 Class Forum
- 17 LFS267 Class Forum
- 16 LFS268 Class Forum
- 14 LFS269 Class Forum
- 194 LFS272 Class Forum
- 1 LFS272-JP クラス フォーラム
- 207 LFW211 Class Forum
- 148 LFW212 Class Forum
- 892 Hardware
- 213 Drivers
- 74 I/O Devices
- 44 Monitors
- 115 Multimedia
- 206 Networking
- 100 Printers & Scanners
- 85 Storage
- 747 Linux Distributions
- 88 Debian
- 64 Fedora
- 13 Linux Mint
- 13 Mageia
- 24 openSUSE
- 133 Red Hat Enterprise
- 33 Slackware
- 13 SUSE Enterprise
- 354 Ubuntu
- 469 Linux System Administration
- 38 Cloud Computing
- 68 Command Line/Scripting
- Github systems admin projects
- 93 Linux Security
- 77 Network Management
- 107 System Management
- 48 Web Management
- 62 Mobile Computing
- 22 Android
- 26 Development
- 1.2K New to Linux
- 1.1K Getting Started with Linux
- 524 Off Topic
- 127 Introductions
- 210 Small Talk
- 19 Study Material
- 783 Programming and Development
- 257 Kernel Development
- 492 Software Development
- 919 Software
- 255 Applications
- 181 Command Line
- 2 Compiling/Installing
- 76 Games
- 316 Installation
- 46 All In Program
- 46 All In Forum
Upcoming Training
-
August 20, 2018
Kubernetes Administration (LFS458)
-
August 20, 2018
Linux System Administration (LFS301)
-
August 27, 2018
Open Source Virtualization (LFS462)
-
August 27, 2018
Linux Kernel Debugging and Security (LFD440)