Hello.

Kyle Moffett wrote:
> Yes, that's what securityfs is there for.  Be mindful, though, that  
Thank you, I see.

> adding a text-based-language parser into securityfs is just as  
> unacceptable as adding a text-based-language parser to procfs.

Now, let me ask for some hints
regarding "text-based-language parsing in the kernel".

It is true that TOMOYO Linux's policy is loaded into kernel
in the text format. But the policy format is very simple.
All policies are
 * sequentially parsable and processable (line-at-a-time, whitespace-delimited).
 * free of stack overflow (no recursive function calls).

I can't imagine differences between
"text-based language parsing" (i.e. policy file in text format) and
"binary-based language parsing" (i.e. policy file in binary format).
Even if I use policy file in binary format, I have to check
whether the loaded policy is corrupted or not.

TOMOYO Linux shares string data as "const char *" type
to reduce memory used by security policy,
and it speeds up string comparison by replacing strcmp() with
pointer comparison.
I can't use pointer to string data (in binary-based policy file)
without verifying there are no duplicated string data in the kernel;
otherwise, functions based on pointer comparison can't work properly.
All other pointers have to be revalidated before I can use.
It makes revalidation function very complicated and large.

I think there exists, more or less, cost for policy validation
in text-based and non-text-based policy.
I doubt that (regarding TOMOYO Linux's policy file)
making non-text-based language parsing worth the cost.

TOMOYO Linux's policy is text-based, but is as simple as comma-separated-values 
(CSV) file.
No difficulty or complexity is needed for validating policy.

Pavel Machek wrote:
> What is that? Language parser in kernel?
Yes, but is sequentially parsable text policy unacceptable?

Regards.
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to