[draft] Add a skill to improve dealing with SELinux denial logs

[vmojzis]

Describe the contribution to the taxonomy

• Add a conscious guide on how to properly deal with an AVC exploring multiple different issues and ways to resolve them.
• Explain how to use the "sesearch" tool to get context for an AVC

Input given at the prompt

What can I do about SELinux AVC logs? 

Response from the original model

╭─────────────────────────────────────────────────── models/merlinite-7b-lab-Q4_K_M.gguf ────────────────────────────────────────────────────╮
│ SELinux (Security-Enhanced Linux) AVC (Access Vector Cache) logs are a crucial component of security in your Linux environment. Here's how │
│ to handle them:                                                                                                                            │
│                                                                                                                                            │
│ 1. Understand the context: Familiarize yourself with the specific SELinux rules and policies that apply to the operation you're            │
│ investigating. This will help you identify the relevant log entries and understand their meaning.                                          │
│ 2. Review permissions and access control: Look for any unauthorized or unexpected access attempts, as well as any issues related to        │
│ permission denials. Understanding how your system's security policy has been enforced is crucial for maintaining a secure environment.     │
│ 3. Analyze audit records: Inspect the SELinux AVC logs to understand how your system's security policy has been enforced over time. This   │
│ can help you identify trends, detect anomalies, and ensure that your security posture remains consistent and effective.                    │
│ 4. Customize logging levels: Similar to general AVC logs, you can adjust the verbosity setting for SELinux AVC logging to control the      │
│ level of detail in the logs. For instance, you might want to log more information when debugging a security issue but reduce the amount of │
│ information logged during normal operation to save resources.                                                                              │
│ 5. Integrate with other tools: If you use a tool like auditd or auditbeat, you can integrate its logging capabilities with your SELinux    │
│ AVC logs to create a comprehensive view of your system's security environment. This can help you diagnose issues more effectively and      │
│ understand the context around any problems that may arise.                                                                                 │
│ 6. Store and process log data: Similar to general AVC logs, you can store the log data in a database or other storage system for further   │
│ analysis. This allows you to generate reports, visualizations, or machine learning models based on the logged information.                 │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────── elapsed 71.964 seconds ─╯

Response from the fine-tuned model

  Waiting for model training to complete (only 13% so far, after 4 days).

Contribution checklist

• [ x ] The contribution was tested with ilab generate
• [ x ] No errors or warnings were produced by ilab generate
• [ x ] All commits are signed off (DCO)
• The qna.yaml file contains at least 5 seed_examples
• [ x ] The qna.yaml file was linted and prettified (yaml-validator can do both)
• [ x ] An attribution.txt file in the same folder as the qna.yaml file
• [ x ] Content does not include PII or otherwise sensitive or confidential information
• [ x ] Content does not include anything documented in the project's Avoid these Topics guidelines

[jjasghar]

@vmojzis please understand we are holding off any changes till the new 0.18.0 release happens. There are some major changes to how the version: 3 will be for qna.yamls and we need it to be released before taking new submissions.

[vmojzis]

@vmojzis please understand we are holding off any changes till the new 0.18.0 release happens. There are some major changes to how the version: 3 will be for qna.yamls and we need it to be released before taking new submissions.

No problem. At least the model training will have time to finish an maybe I'll need to adjust the seeds based on the results.
Can I leave the PR open and just update it once the new release is out?

[jjasghar]

Yep! Please over it to a "draft" if you can. Otherwise you'll get marked stale eventually.

[github-actions]

This pull request has been automatically marked as stale because it has not had activity within 15 days. It will be automatically closed if no further activity occurs within the next 31 days.

[ivanbaldo]

Please note that the new instructlab 0.18.x has been released, so this work can continue.

[github-actions]

This pull request has been automatically marked as stale because it has not had activity within 15 days. It will be automatically closed if no further activity occurs within the next 31 days.

[instruct-lab-bot]

Beep, boop 🤖, Hi, I'm @instructlab-bot and I'm going to help you with your pull request. Thanks for you contribution! 🎉

I support the following commands:

• @instructlab-bot precheck -- Check existing model behavior using the questions in this proposed change.
• @instructlab-bot generate -- Generate a sample of synthetic data using the synthetic data generation backend infrastructure.
• @instructlab-bot generate-local -- Generate a sample of synthetic data using a local model.
• @instructlab-bot help -- Print this help message again.

Note

Results or Errors of these commands will be posted as a pull request check in the Checks section below

Note

Currently only maintainers belongs to [[taxonomy-triagers taxonomy-approvers taxonomy-maintainers instructlab-bot-triagers instructlab-bot-maintainers oversight-committee]] teams are allowed to run these commands.