On Sep 18, 2007, at 14:39:47, Tetsuo Handa wrote:
Kyle Moffett wrote:
Yes, that's what securityfs is there for.
Thank you, I see.
Be mindful, though, that 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.
From personal experience trying to validate a good binary format is
*MUCH* easier than trying to validate an equally expressive text
format. Typically a good binary format will have string *length*
values encoded inside of it, so you can allocate memory in advance
and easily know exactly where the next value is supposed to start.
Also your "text" policy is hardly simple and a relatively brief
inspection of your "conditional permission" parsing code seems to
validate that.
Look at it this way: What format do you use for your in-memory
datastructures? If that format is not extremely close to the policy
file format (with pointers replaced by 8-byte offsets), then you are
using the wrong binary format. The more manipulations you have to do
to a complicated data-structure the more likely you are to have a
buffer-overflow or parsing bug.
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.
This paragraph doesn't parse. If you can make some optimization
using a text policy then you can do the same with the "binary"
datastructures into which your policy is parsed *in* *memory*.
Therefore you can just skip the text-in-the-kernel and send the
binary policy there directly.
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.
You will need to prove that to multiple reviewers with many
examples. There is precedent in the way SELinux does things and
historically we have tried very hard to avoid putting text parsing of
*ANY* kind into the kernel.
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.
And with this one statement you blew your whole argument. There are
arguably more CSV-file parsers with syntax bugs or buffer overflows
than any other type of file. CSV is actually *very* complicated to
get right as anybody who has actually had to implement one will know.
Cheers,
Kyle Moffett
-
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
