All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: "Spector, Aaron" <Aaron_Spector@mcafee.com>,
	"SELinux (selinux@tycho.nsa.gov)" <selinux@tycho.nsa.gov>,
	"Paul Moore (paul@paul-moore.com)" <paul@paul-moore.com>
Subject: Re: Switching to enforcing mode introduces new policy issues?
Date: Fri, 24 Apr 2015 12:11:38 -0400	[thread overview]
Message-ID: <553A6B3A.70108@tycho.nsa.gov> (raw)
In-Reply-To: <553A693A.5080807@tycho.nsa.gov>

On 04/24/2015 12:03 PM, Stephen Smalley wrote:
> On 04/24/2015 11:57 AM, Spector, Aaron wrote:
>> That's what I thought with regards to the file opens. It seemed to work when I lacked the directory search permission, but once it came up and I thought about it, it made sense. I'm just not sure why I didn't see the deny in permissive mode.. All of the rules I have had to add have made sense in the grand scheme of things.
>>
>> Is it possible to examine the cache for what lookups have happened, similar to how sesearch works? Perhaps my permissive mode is actually denying some operations, but not telling me for some reason.
> 
> No, the only information about the AVC that is made available to
> userspace is statistics via /sys/fs/selinux/avc/cache_stats and hash_stats.
> 
> I don't think your permissive mode is denying anything.  The more likely
> scenario is audit is just losing events IMHO.  Looking again at the
> code, even the audit_lost output is wrapped with a printk_ratelimit
> check, so it could be suppressed.
> 
>> If I was rolling over the kernel ring buffer, wouldn't I be missing the initial boot events? I've got the entire boot sequence in dmesg.
> 
> Yes, so it doesn't sound like you are rolling over that buffer.
> 
> Sounds like a bug in audit to me...

Just wanted to check - it sounds like you are not running auditd at all?
 Just letting all of the audit messages go to dmesg?

  parent reply	other threads:[~2015-04-24 16:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-23 21:14 Switching to enforcing mode introduces new policy issues? Spector, Aaron
2015-04-23 22:19 ` Paul Moore
2015-04-24  4:12   ` Spector, Aaron
2015-04-24  4:53     ` Gaurav Gangwar
2015-04-24 13:47       ` Spector, Aaron
2015-04-24 12:17     ` Miroslav Grepl
2015-04-24 12:25 ` Stephen Smalley
2015-04-24 15:18   ` Spector, Aaron
2015-04-24 15:27     ` Stephen Smalley
2015-04-24 15:57       ` Spector, Aaron
2015-04-24 16:03         ` Stephen Smalley
2015-04-24 16:05           ` Stephen Smalley
2015-04-24 16:11           ` Stephen Smalley [this message]
2015-04-24 16:30             ` Spector, Aaron
2015-04-24 16:33               ` Stephen Smalley
2015-04-24 16:36                 ` Stephen Smalley
2015-04-24 20:37                   ` Spector, Aaron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=553A6B3A.70108@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=Aaron_Spector@mcafee.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.