Hi,
there are neither categories nor MLS used on the system. I'll get the amount of different types used by the system (I need to do some digging, will get the data tomorrow). Most of classes will be regular file, directories and some symbolic links. There will be a lots of files as AFAIK vertica uses lots of smaller files.
I'll try to reduce amount of dontaudit rules and I'll see how much this reduces cache misses. The hard truth is, that vertica is looking at many places during the run, most of which it does not need. Maybe the way we have rules defined is creating a lot of stress on the amount of rules in the policy, I'll try to get the data on that.
On Tue, Dec 8, 2015 at 4:35 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 12/08/2015 09:56 AM, Michal Marciniszyn wrote:
Hi Dominic,
while there is quite a lot of dontaudit rules around, the amount for
domains running on this node is not high. Is there any way how to
monitor which rules are loaded and released from the cache? Anything
better than plain aggregated stats? We would bot care about performance
of such monitoring tool if it provides some useful answer. For instance,
is there a way how to use system tap or similar kernel profiling to get
the data?
I'll do a profiling on how many rules actually apply for the domains on
the node (i.e. use sesearch to find out). If doing so, does the rule in
cache hold whole vector (i.e. A is allowed to do X, Y, Z on B or is one
cache entry A can do X on B)?
One cache entry holds the entire access vector. However, they are unique per (source context, target context, target class) triple.
Are you using categories on this system (i.e. running processes in specific category sets, assigning specific categories to files), or just types?
How many unique domains are running in your workload? How many file types are typically accessed by your workload? How many different kinds of files (regular, directory, symbolic link, block device, ...) are part of your workload?
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
