Re: missing avc message field names
>>> Steve G wrote:
>>>
I'd also like to make sure that all AVCs really are AVCs. I think there are
some error messages that come out as AVCs when they should be SE_ERR or
USER_SE_ERR.
This is a separate issue, this results from the userspace AVC's logging
callback not having a type field. I'm aware of this problem and willing
to fix it but I'd like to get a clear picture of what the final auditing
format will be first, so I'm glad this discussion is taking place.
You already have them split out...or did you totally skip
AUDIT_USER_AVC? So,
you already have to solve the problem so why not generalize the solution? The
parsing API should be able to help with this. If you tell it to get all the
different types and they don't exist, you don't get a hit except the ones
that do exist.
My point here was simply to warn in advance that userspace object
managers will in general introduce widely varying fields to their AVC
messages and that the auditing record format should be equipped to deal
with that. Who knows what types of objects will appear in these
messages in the future: there might be SELinux-enhanced e-mail clients,
office applications, file managers in the future. Making the dictionary
easily extensible now will likely pay off later and the prefix idea is a
way to do that.
As far as binary records go, if that is the future direction then I
don't see why the disk space argument is being made for not having a
prefix. Presumably in binary form the keywords will be assigned
numbers that are fixed size, so that the length of the string
representation shouldn't matter. And even in text form if the logs are
compressed then the length issue will be mediated.
>
I doubt there very many security related pieces of information that is not
already in the dictionary. There are a finite number of security objects and
their attributes.
Again I think that the audit system should support future expansion if
it's going to be the new way for handling AVC's and other security events.
> And what about third-party tools that are security critical?
>
They have the TRUSTED_APP message type and they can put anything in that they
want. I consider that one completely freestyle.
How does this work with binary records? How will these messages be
searched?
Nearly all names are unique (and the problem should be solved when I
code up
seperm and seresults). Adding more letters to the name eats the diskspace. We
only do it when necessary. That is what drives the choice of "res" instead
of "results" for the audit system.
I do think it should be selinux.perms, selinux.result and the other AVC
stuff should be selinux.foo. These are long names I concede but they
are clearer and log size is already an issue anyway, moving to
compressed or binary will solve the problem.