Skip to content
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

Regression in proc.aname list comparison in libs > 0.17.x #2018

Closed
LucaGuerra opened this issue Aug 26, 2024 · 2 comments · Fixed by #2019
Closed

Regression in proc.aname list comparison in libs > 0.17.x #2018

LucaGuerra opened this issue Aug 26, 2024 · 2 comments · Fixed by #2019
Labels
kind/bug Something isn't working
Milestone

Comments

@LucaGuerra
Copy link
Contributor

LucaGuerra commented Aug 26, 2024

Describe the bug

From: https://falco.org/docs/reference/rules/supported-fields/

The proc.name (truncated after 16 characters) for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.aname[1] retrieves the proc.name of the parent process, proc.aname[2] retrieves the proc.name of the grandparent process, and so on. The current process's proc.name line can be obtained using proc.aname[0]. When used without any arguments, proc.aname is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.aname=bash to match any process ancestor whose name is bash.

This is no longer working and aname only matches the current process name. Falco 0.38.x appears to be unaffected but I can reproduce the issue on the latest libs.

How to reproduce it

TEST_F(sinsp_with_test_input, contains_aname)
{
	DEFAULT_TREE

	/* Now we call an execve on p6_t1 */
	auto evt = generate_execve_enter_and_exit_event(0, p6_t1_tid, p6_t1_tid, p6_t1_pid, p6_t1_ptid, "/good-exe", "good-exe", "/good-exe");

	printf("proc.aname[0]=%s, proc.aname[1]=%s, proc.aname[2]=%s, proc.aname[3]=%s, proc.aname[4]=%s, proc.aname[5]=%s\n", 
		get_field_as_string(evt, "proc.aname[0]").c_str(),
		get_field_as_string(evt, "proc.aname[1]").c_str(),
		get_field_as_string(evt, "proc.aname[2]").c_str(),
		get_field_as_string(evt, "proc.aname[3]").c_str(),
		get_field_as_string(evt, "proc.aname[4]").c_str(),
		get_field_as_string(evt, "proc.aname[5]").c_str());

	EXPECT_TRUE(eval_filter(evt, "proc.aname in (init)")); // fail
	EXPECT_TRUE(eval_filter(evt, "proc.aname in (bash)")); // fail
	EXPECT_TRUE(eval_filter(evt, "proc.aname in (good-exe, init)")); // fail
	EXPECT_TRUE(eval_filter(evt, "proc.aname = bash")); // ok
	EXPECT_TRUE(eval_filter(evt, "proc.aname = init")); // ok

	EXPECT_FALSE(eval_filter(evt, "proc.aname in (good-exe)")); // ok -- docs unclear but I think it's right
	EXPECT_FALSE(eval_filter(evt, "proc.aname = good-exe")); // ok -- docs unclear but I think it's right
	EXPECT_FALSE(eval_filter(evt, "proc.aname in (bad-exe)")); // ok
}

Expected behaviour

All tests above passing

Screenshots

Environment

  • Falco version: libs master 9d76298

Additional context

Found from Falco test failure: falcosecurity/falco#3283

@LucaGuerra LucaGuerra added the kind/bug Something isn't working label Aug 26, 2024
@LucaGuerra
Copy link
Contributor Author

/milestone 0.18.0

@FedeDP
Copy link
Contributor

FedeDP commented Aug 26, 2024

Thanks for tracking and the providing the test!

@LucaGuerra LucaGuerra changed the title Regression in proc.aname comparison in libs > 0.17.x Regression in proc.aname list comparison in libs > 0.17.x Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants