-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interactive bash command might be missed/lost under some circumstances #490
Comments
|
Screencast.from.02-25-2024.04.20.16.PM.webmHere is the demo for Some contexts: |
I reproduced it too. The key to reproducibility is whether to execute the |
Screencast.from.02-28-2024.08.59.42.PM.webmActually, in my computer without executing the So, I try to reproduced the similar result as yours in the video above after setting To confirm it, run in your initial type exec As for the fix for the missing command, in my opinion, more discussion is needed before really finding out the relatively weird behavior on your computer. Also the fix option I proposed (i.e., removing the support for returned value tracking) is a breaking change( removing a feature ), which may significantly contradicts your original design decision and the use case for eCapture. So I want to ask for your advice. Would it better to remove the support for returned value tracing? Are there better option that I do not know without breaking the original feature Finally, I confine the analysis the inherent defect for return value analysis on my initial comment:
Best wishes! |
Indeed, the original intention of eCapture's design was to track "input commands" without including return values. However, it does not mean that "return value tracking cannot be supported". However, the current main goal is to determine the root cause of the problem. |
In a word, the root cause is that |
So, what is your solution? Remove the detection of @sancppp, what do you think about this issue? |
I come up with three potential solution with different consideration:
|
I agree with 3, but it may require extensive testing. |
QQ20240302-214301.mp4 |
Another great example that shows the difficulties to correctly trace both every the returned value and command line. |
in my opinion:
|
Signed-off-by: ruitianzhong <ruitian-zhong@outlook.com>
Describe the bug
Under some circumstances bash command would be missed, which would not occur when using
bashreadline
from BCC by contrast.Catching all interactive bash shell commands in my opinion is critically important for the auditing.
To Reproduce
start ecapture under bash mode:
Example 1
ecapture will show nothing in this case.
Example 2
ecapture will only show
fi
in this case.By contrast, ecapture's counterpart
bashreadline
show correct results even when executing interactive bash expression which does not track returned value at all.Analysis
This bug is due to the track of return value of the executed program.
In example 1, the built-in
exec
command would not fork a process to execute new program. Instead, it directly callexecve
in the process of bash itself, which causeexecute_command()
in Bash never return (verified through debugging). Thus ecapture can not get the return value and print out the command by hookingexecute_command()
. It will also cause memory leak because bpf_map_delete_elem will not be executed any time soon.In example 2, although the first three lines have been recorded in the map by the order (override the previous one), they are not printed out because they have not been really executed and thus have no return value leading to the printed message. When
fi
is input finally, it has return value and is printed out as a result.Fix option
In my opinion, it would be better to not track return value in bash mode. Actually not every line of interactive bash command has a return value and it might introduce overhead to accurately track every line of interactive bash command while catching the return value.
If needed, I can take a Pull Request to fix it.
The text was updated successfully, but these errors were encountered: