[PATCH] SELinux: open perms on sockets, AF_UNIX

[PATCH] SELinux: open perms on sockets, AF_UNIX

[Eric Paris]

When I did open permissions I didn't think any sockets would have an open.
Turns out AF_UNIX sockets can have an open when they are bound to the
filesystem namespace.  This patch adds a new SOCK_FILE__OPEN permission.
It's safe to add this as the open perms are already predicated on
capabilities and capabilities means we have unknown perm handling so
systems should be as backwards compatible as the policy wants them to
be.

https://bugzilla.redhat.com/show_bug.cgi?id=475224

Signed-off-by: Eric Paris <eparis@redhat.com>
---

This is pretty much untested (just compiled) as I can't get linux-next
to boot. (i'm a bit scared to turn off the redzone overwrite detection
that is killing it, but I'll try in the morning)  It should be obvious
and safe.  This might be unwarrented, does anyone see a use in providing
an open distinction on AF_UNIX sockets?  Are we happy with the socket
perms that are already there?  Who thinks I should just silence the
dmesg spam?

 security/selinux/hooks.c                     |    2 ++
 security/selinux/include/av_perm_to_string.h |    2 ++
 security/selinux/include/av_permissions.h    |    2 ++
 3 files changed, 6 insertions(+), 0 deletions(-)


diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 51e8c75..984f0af 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1800,6 +1800,8 @@ static inline u32 open_file_to_av(struct file *file)
 			av |= FIFO_FILE__OPEN;
 		else if (S_ISDIR(mode))
 			av |= DIR__OPEN;
+		else if (S_ISSOCK(mode))
+			av |= SOCK_FILE__OPEN;
 		else
 			printk(KERN_ERR "SELinux: WARNING: inside %s with "
 				"unknown mode:%o\n", __func__, mode);
diff --git a/security/selinux/include/av_perm_to_string.h b/security/selinux/include/av_perm_to_string.h
index c0c8854..31df1d7 100644
--- a/security/selinux/include/av_perm_to_string.h
+++ b/security/selinux/include/av_perm_to_string.h
@@ -24,6 +24,7 @@
    S_(SECCLASS_CHR_FILE, CHR_FILE__EXECMOD, "execmod")
    S_(SECCLASS_CHR_FILE, CHR_FILE__OPEN, "open")
    S_(SECCLASS_BLK_FILE, BLK_FILE__OPEN, "open")
+   S_(SECCLASS_SOCK_FILE, SOCK_FILE__OPEN, "open")
    S_(SECCLASS_FIFO_FILE, FIFO_FILE__OPEN, "open")
    S_(SECCLASS_FD, FD__USE, "use")
    S_(SECCLASS_TCP_SOCKET, TCP_SOCKET__CONNECTTO, "connectto")
@@ -152,6 +153,7 @@
    S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_WRITE, "nlmsg_write")
    S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_RELAY, "nlmsg_relay")
    S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_READPRIV, "nlmsg_readpriv")
+   S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_TTY_AUDIT, "nlmsg_tty_audit")
    S_(SECCLASS_NETLINK_IP6FW_SOCKET, NETLINK_IP6FW_SOCKET__NLMSG_READ, "nlmsg_read")
    S_(SECCLASS_NETLINK_IP6FW_SOCKET, NETLINK_IP6FW_SOCKET__NLMSG_WRITE, "nlmsg_write")
    S_(SECCLASS_ASSOCIATION, ASSOCIATION__SENDTO, "sendto")
diff --git a/security/selinux/include/av_permissions.h b/security/selinux/include/av_permissions.h
index 0ba79fe..d645192 100644
--- a/security/selinux/include/av_permissions.h
+++ b/security/selinux/include/av_permissions.h
@@ -174,6 +174,7 @@
 #define SOCK_FILE__SWAPON                         0x00004000UL
 #define SOCK_FILE__QUOTAON                        0x00008000UL
 #define SOCK_FILE__MOUNTON                        0x00010000UL
+#define SOCK_FILE__OPEN                           0x00020000UL
 #define FIFO_FILE__IOCTL                          0x00000001UL
 #define FIFO_FILE__READ                           0x00000002UL
 #define FIFO_FILE__WRITE                          0x00000004UL
@@ -707,6 +708,7 @@
 #define NETLINK_AUDIT_SOCKET__NLMSG_WRITE         0x00800000UL
 #define NETLINK_AUDIT_SOCKET__NLMSG_RELAY         0x01000000UL
 #define NETLINK_AUDIT_SOCKET__NLMSG_READPRIV      0x02000000UL
+#define NETLINK_AUDIT_SOCKET__NLMSG_TTY_AUDIT     0x04000000UL
 #define NETLINK_IP6FW_SOCKET__IOCTL               0x00000001UL
 #define NETLINK_IP6FW_SOCKET__READ                0x00000002UL
 #define NETLINK_IP6FW_SOCKET__WRITE               0x00000004UL



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] SELinux: open perms on sockets, AF_UNIX

[James Morris]

On Tue, 9 Dec 2008, Eric Paris wrote:

> 
> This is pretty much untested (just compiled) as I can't get linux-next
> to boot. (i'm a bit scared to turn off the redzone overwrite detection
> that is killing it, but I'll try in the morning) 

Can you test it against security-testing?


-- 
James Morris <jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] SELinux: open perms on sockets, AF_UNIX

[Stephen Smalley]

On Tue, 2008-12-09 at 18:31 -0500, Eric Paris wrote:
> When I did open permissions I didn't think any sockets would have an open.
> Turns out AF_UNIX sockets can have an open when they are bound to the
> filesystem namespace.  This patch adds a new SOCK_FILE__OPEN permission.
> It's safe to add this as the open perms are already predicated on
> capabilities and capabilities means we have unknown perm handling so
> systems should be as backwards compatible as the policy wants them to
> be.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=475224
> 
> Signed-off-by: Eric Paris <eparis@redhat.com>
> ---
> 
> This is pretty much untested (just compiled) as I can't get linux-next
> to boot. (i'm a bit scared to turn off the redzone overwrite detection
> that is killing it, but I'll try in the morning)  It should be obvious
> and safe.  This might be unwarrented, does anyone see a use in providing
> an open distinction on AF_UNIX sockets?  Are we happy with the socket
> perms that are already there?  Who thinks I should just silence the
> dmesg spam?
> 
>  security/selinux/hooks.c                     |    2 ++
>  security/selinux/include/av_perm_to_string.h |    2 ++
>  security/selinux/include/av_permissions.h    |    2 ++
>  3 files changed, 6 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 51e8c75..984f0af 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1800,6 +1800,8 @@ static inline u32 open_file_to_av(struct file *file)
>  			av |= FIFO_FILE__OPEN;
>  		else if (S_ISDIR(mode))
>  			av |= DIR__OPEN;
> +		else if (S_ISSOCK(mode))
> +			av |= SOCK_FILE__OPEN;
>  		else
>  			printk(KERN_ERR "SELinux: WARNING: inside %s with "
>  				"unknown mode:%o\n", __func__, mode);
> diff --git a/security/selinux/include/av_perm_to_string.h b/security/selinux/include/av_perm_to_string.h
> index c0c8854..31df1d7 100644
> --- a/security/selinux/include/av_perm_to_string.h
> +++ b/security/selinux/include/av_perm_to_string.h
> @@ -24,6 +24,7 @@
>     S_(SECCLASS_CHR_FILE, CHR_FILE__EXECMOD, "execmod")
>     S_(SECCLASS_CHR_FILE, CHR_FILE__OPEN, "open")
>     S_(SECCLASS_BLK_FILE, BLK_FILE__OPEN, "open")
> +   S_(SECCLASS_SOCK_FILE, SOCK_FILE__OPEN, "open")
>     S_(SECCLASS_FIFO_FILE, FIFO_FILE__OPEN, "open")
>     S_(SECCLASS_FD, FD__USE, "use")
>     S_(SECCLASS_TCP_SOCKET, TCP_SOCKET__CONNECTTO, "connectto")
> @@ -152,6 +153,7 @@
>     S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_WRITE, "nlmsg_write")
>     S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_RELAY, "nlmsg_relay")
>     S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_READPRIV, "nlmsg_readpriv")
> +   S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_TTY_AUDIT, "nlmsg_tty_audit")

Unrelated diff?  Defined in refpolicy yet?

>     S_(SECCLASS_NETLINK_IP6FW_SOCKET, NETLINK_IP6FW_SOCKET__NLMSG_READ, "nlmsg_read")
>     S_(SECCLASS_NETLINK_IP6FW_SOCKET, NETLINK_IP6FW_SOCKET__NLMSG_WRITE, "nlmsg_write")
>     S_(SECCLASS_ASSOCIATION, ASSOCIATION__SENDTO, "sendto")
> diff --git a/security/selinux/include/av_permissions.h b/security/selinux/include/av_permissions.h
> index 0ba79fe..d645192 100644
> --- a/security/selinux/include/av_permissions.h
> +++ b/security/selinux/include/av_permissions.h
> @@ -174,6 +174,7 @@
>  #define SOCK_FILE__SWAPON                         0x00004000UL
>  #define SOCK_FILE__QUOTAON                        0x00008000UL
>  #define SOCK_FILE__MOUNTON                        0x00010000UL
> +#define SOCK_FILE__OPEN                           0x00020000UL
>  #define FIFO_FILE__IOCTL                          0x00000001UL
>  #define FIFO_FILE__READ                           0x00000002UL
>  #define FIFO_FILE__WRITE                          0x00000004UL
> @@ -707,6 +708,7 @@
>  #define NETLINK_AUDIT_SOCKET__NLMSG_WRITE         0x00800000UL
>  #define NETLINK_AUDIT_SOCKET__NLMSG_RELAY         0x01000000UL
>  #define NETLINK_AUDIT_SOCKET__NLMSG_READPRIV      0x02000000UL
> +#define NETLINK_AUDIT_SOCKET__NLMSG_TTY_AUDIT     0x04000000UL

Ditto.

>  #define NETLINK_IP6FW_SOCKET__IOCTL               0x00000001UL
>  #define NETLINK_IP6FW_SOCKET__READ                0x00000002UL
>  #define NETLINK_IP6FW_SOCKET__WRITE               0x00000004UL
> 
> 
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] SELinux: open perms on sockets, AF_UNIX

[Eric Paris]

On Wed, 2008-12-10 at 08:33 -0500, Stephen Smalley wrote:

> > diff --git a/security/selinux/include/av_perm_to_string.h b/security/selinux/include/av_perm_to_string.h
> > index c0c8854..31df1d7 100644
> > --- a/security/selinux/include/av_perm_to_string.h
> > +++ b/security/selinux/include/av_perm_to_string.h
> > @@ -24,6 +24,7 @@
> >     S_(SECCLASS_CHR_FILE, CHR_FILE__EXECMOD, "execmod")
> >     S_(SECCLASS_CHR_FILE, CHR_FILE__OPEN, "open")
> >     S_(SECCLASS_BLK_FILE, BLK_FILE__OPEN, "open")
> > +   S_(SECCLASS_SOCK_FILE, SOCK_FILE__OPEN, "open")
> >     S_(SECCLASS_FIFO_FILE, FIFO_FILE__OPEN, "open")
> >     S_(SECCLASS_FD, FD__USE, "use")
> >     S_(SECCLASS_TCP_SOCKET, TCP_SOCKET__CONNECTTO, "connectto")
> > @@ -152,6 +153,7 @@
> >     S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_WRITE, "nlmsg_write")
> >     S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_RELAY, "nlmsg_relay")
> >     S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_READPRIV, "nlmsg_readpriv")
> > +   S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_TTY_AUDIT, "nlmsg_tty_audit")
> 
> Unrelated diff?  Defined in refpolicy yet?

Defined in policy, I'll run down if it is in refpolicy or only in the
fedora policy (diff was created using fedora's latest policy).  Either
way I think I need to get it fixed in refpolicy (and make use of it in
upstream kernel but obviously that's another patch.)


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] SELinux: open perms on sockets, AF_UNIX

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Paris wrote:
> On Wed, 2008-12-10 at 08:33 -0500, Stephen Smalley wrote:
> 
>>> diff --git a/security/selinux/include/av_perm_to_string.h b/security/selinux/include/av_perm_to_string.h
>>> index c0c8854..31df1d7 100644
>>> --- a/security/selinux/include/av_perm_to_string.h
>>> +++ b/security/selinux/include/av_perm_to_string.h
>>> @@ -24,6 +24,7 @@
>>>     S_(SECCLASS_CHR_FILE, CHR_FILE__EXECMOD, "execmod")
>>>     S_(SECCLASS_CHR_FILE, CHR_FILE__OPEN, "open")
>>>     S_(SECCLASS_BLK_FILE, BLK_FILE__OPEN, "open")
>>> +   S_(SECCLASS_SOCK_FILE, SOCK_FILE__OPEN, "open")
>>>     S_(SECCLASS_FIFO_FILE, FIFO_FILE__OPEN, "open")
>>>     S_(SECCLASS_FD, FD__USE, "use")
>>>     S_(SECCLASS_TCP_SOCKET, TCP_SOCKET__CONNECTTO, "connectto")
>>> @@ -152,6 +153,7 @@
>>>     S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_WRITE, "nlmsg_write")
>>>     S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_RELAY, "nlmsg_relay")
>>>     S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_READPRIV, "nlmsg_readpriv")
>>> +   S_(SECCLASS_NETLINK_AUDIT_SOCKET, NETLINK_AUDIT_SOCKET__NLMSG_TTY_AUDIT, "nlmsg_tty_audit")
>> Unrelated diff?  Defined in refpolicy yet?
> 
> Defined in policy, I'll run down if it is in refpolicy or only in the
> fedora policy (diff was created using fedora's latest policy).  Either
> way I think I need to get it fixed in refpolicy (and make use of it in
> upstream kernel but obviously that's another patch.)
> 
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

You mean this patch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk/6foACgkQrlYvE4MpobOS4gCfToVdCVOeOol52v46C4kOyCDx
CDgAoJ9Za1wHSEq6dvn46IggC1ZIARwN
=PcJV
-----END PGP SIGNATURE-----

[-- Attachment #2: flask_access_vectors.patch --]
[-- Type: text/plain, Size: 286 bytes --]

--- nsaserefpolicy/policy/flask/access_vectors	2008-10-17 08:49:14.000000000 -0400
+++ serefpolicy-3.5.13/policy/flask/access_vectors	2008-11-24 10:49:49.000000000 -0500
@@ -616,6 +616,7 @@
 	nlmsg_write
 	nlmsg_relay
 	nlmsg_readpriv
+	nlmsg_tty_audit
 }
 
 class netlink_ip6fw_socket

[-- Attachment #3: flask_access_vectors.patch.sig --]
[-- Type: application/octet-stream, Size: 72 bytes --]

Avc denies while running in Permissive mode...

[Hasan Rezaul-CHR010]

Hi All,

Lets just say in my product, we are not confident enough to run in
Enforcing mode just yet !

I used Fedora Core 7 *strict* policy as my base policy, and built my own
additional myModule.pp policies on top of that. So, I have *strict*
SELinux policy running on an embedded Linux Card, in Permissive mode.

Due to auto-relabelling of the filesystem, files in the  /etc/
directory get appropriately labelled as  etc_t (as desired).

I have myModule.pp policy lines that say :

neverallow user_t etc_t:file write;
neverallow user_t etc_t:dir write;

My question is:

When I ssh in as a test user with a security context =
[user_u:user_r:user_t], and I attempt to modify/write some file in the
/etc/  directory,  I do get an avc deny message in the audit.log file,
as desired  :-)

But subsequent attempts to do the same thing doesn't generate any more
avc denies ??? In other words, when I attempt to modify the same file
again, or modify a different file under /etc/  as the same test user...
I DON'T get any more avc deny messages ?!?

I know that if I switch from Permissive to Enforcing mode, I get avc
deny msgs for EVERY single violation !

But in Permissive mode, I would like to also get a deny for every
violation attempt.. How do I achieve this ?

Because I am running with *strict* policy, during normal operation of my
Linux card, I have numerous avc deny messages that pop up from time to
time. So I collect all those deny messages, run audit2allow on them, and
try to eliminate these denies in the policy.  

But what confuses me is that, there are some avc denies that seem to be
about the same operation, and those avc denies keep popping up
repeatedly in the Permissive mode... Why then cant the scenario
described above produce repeated avc denies ???

I understand that there is a mechanism to prevent flooding of avc denies
in Permissive mode. And I did try to change the
/selinux/avc/cache_threshold file, by putting a "1" there instead of
"512". But doing that causes a lot of CPU to be chewed up by SELinux.   

Any other suggestions for why the scenario I described above, about a
test user (user_t), trying to modify multiple files under the /etc/
directory creates only one avc deny message, and doesn't generate an avc
deny for each attempt ???

Apologize for the long mail. Thanks in advance for your help,

- Rezaul.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Avc denies while running in Permissive mode...

[Stephen Smalley]

On Wed, 2008-12-17 at 12:08 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> Lets just say in my product, we are not confident enough to run in
> Enforcing mode just yet !
> 
> I used Fedora Core 7 *strict* policy as my base policy, and built my own
> additional myModule.pp policies on top of that. So, I have *strict*
> SELinux policy running on an embedded Linux Card, in Permissive mode.
> 
> Due to auto-relabelling of the filesystem, files in the  /etc/
> directory get appropriately labelled as  etc_t (as desired).
> 
> I have myModule.pp policy lines that say :
> 
> neverallow user_t etc_t:file write;
> neverallow user_t etc_t:dir write;
> 
> My question is:
> 
> When I ssh in as a test user with a security context =
> [user_u:user_r:user_t], and I attempt to modify/write some file in the
> /etc/  directory,  I do get an avc deny message in the audit.log file,
> as desired  :-)
> 
> But subsequent attempts to do the same thing doesn't generate any more
> avc denies ??? In other words, when I attempt to modify the same file
> again, or modify a different file under /etc/  as the same test user...
> I DON'T get any more avc deny messages ?!?
> 
> I know that if I switch from Permissive to Enforcing mode, I get avc
> deny msgs for EVERY single violation !
> 
> But in Permissive mode, I would like to also get a deny for every
> violation attempt.. How do I achieve this ?
> 
> Because I am running with *strict* policy, during normal operation of my
> Linux card, I have numerous avc deny messages that pop up from time to
> time. So I collect all those deny messages, run audit2allow on them, and
> try to eliminate these denies in the policy.  
> 
> But what confuses me is that, there are some avc denies that seem to be
> about the same operation, and those avc denies keep popping up
> repeatedly in the Permissive mode... Why then cant the scenario
> described above produce repeated avc denies ???
> 
> I understand that there is a mechanism to prevent flooding of avc denies
> in Permissive mode. And I did try to change the
> /selinux/avc/cache_threshold file, by putting a "1" there instead of
> "512". But doing that causes a lot of CPU to be chewed up by SELinux.   
> 
> Any other suggestions for why the scenario I described above, about a
> test user (user_t), trying to modify multiple files under the /etc/
> directory creates only one avc deny message, and doesn't generate an avc
> deny for each attempt ???
> 
> Apologize for the long mail. Thanks in advance for your help,

In permissive mode, when a permission would be denied for a given
(source context, target context, target class) triple for the first
time, the kernel audits the denial (avc:  denied) and then adds that
permission to the allowed vector for that triple in the AVC (access
vector cache).  Thus, subsequent uses of that same permission on that
same triple will not trigger further denials until the cache entry is
evicted from the cache (which can happen automatically if we need to
free up space for use by other entries or explicitly upon either a
policy reload or changing a policy boolean).

So you might for example see avc denials with different permissions on
the same triple or avc denials with the same permission on different
triples.  You may also see avc denials with the same permission and the
same triple across a period of time if the cache entry was evicted in
between the two avc denials.

In terms of getting the behavior you want (i.e. see all instances of an
avc denial), you really only have these choices without modifying code:
1) use enforcing mode, or
2) set the cache threshold to 1

Or you could modify the kernel for your development purposes.  It would
be a pretty trivial patch.  What's your base kernel version?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Avc denies while running in Permissive mode...

[Eric Paris]

On Wed, 2008-12-17 at 12:42 -0500, Stephen Smalley wrote:
> On Wed, 2008-12-17 at 12:08 -0500, Hasan Rezaul-CHR010 wrote:
> > Hi All,
> > 
> > Lets just say in my product, we are not confident enough to run in
> > Enforcing mode just yet !
> > 
> > I used Fedora Core 7 *strict* policy as my base policy, and built my own
> > additional myModule.pp policies on top of that. So, I have *strict*
> > SELinux policy running on an embedded Linux Card, in Permissive mode.
> > 
> > Due to auto-relabelling of the filesystem, files in the  /etc/
> > directory get appropriately labelled as  etc_t (as desired).
> > 
> > I have myModule.pp policy lines that say :
> > 
> > neverallow user_t etc_t:file write;
> > neverallow user_t etc_t:dir write;
> > 
> > My question is:
> > 
> > When I ssh in as a test user with a security context =
> > [user_u:user_r:user_t], and I attempt to modify/write some file in the
> > /etc/  directory,  I do get an avc deny message in the audit.log file,
> > as desired  :-)
> > 
> > But subsequent attempts to do the same thing doesn't generate any more
> > avc denies ??? In other words, when I attempt to modify the same file
> > again, or modify a different file under /etc/  as the same test user...
> > I DON'T get any more avc deny messages ?!?
> > 
> > I know that if I switch from Permissive to Enforcing mode, I get avc
> > deny msgs for EVERY single violation !
> > 
> > But in Permissive mode, I would like to also get a deny for every
> > violation attempt.. How do I achieve this ?
> > 
> > Because I am running with *strict* policy, during normal operation of my
> > Linux card, I have numerous avc deny messages that pop up from time to
> > time. So I collect all those deny messages, run audit2allow on them, and
> > try to eliminate these denies in the policy.  
> > 
> > But what confuses me is that, there are some avc denies that seem to be
> > about the same operation, and those avc denies keep popping up
> > repeatedly in the Permissive mode... Why then cant the scenario
> > described above produce repeated avc denies ???
> > 
> > I understand that there is a mechanism to prevent flooding of avc denies
> > in Permissive mode. And I did try to change the
> > /selinux/avc/cache_threshold file, by putting a "1" there instead of
> > "512". But doing that causes a lot of CPU to be chewed up by SELinux.   
> > 
> > Any other suggestions for why the scenario I described above, about a
> > test user (user_t), trying to modify multiple files under the /etc/
> > directory creates only one avc deny message, and doesn't generate an avc
> > deny for each attempt ???
> > 
> > Apologize for the long mail. Thanks in advance for your help,
> 
> In permissive mode, when a permission would be denied for a given
> (source context, target context, target class) triple for the first
> time, the kernel audits the denial (avc:  denied) and then adds that
> permission to the allowed vector for that triple in the AVC (access
> vector cache).  Thus, subsequent uses of that same permission on that
> same triple will not trigger further denials until the cache entry is
> evicted from the cache (which can happen automatically if we need to
> free up space for use by other entries or explicitly upon either a
> policy reload or changing a policy boolean).
> 
> So you might for example see avc denials with different permissions on
> the same triple or avc denials with the same permission on different
> triples.  You may also see avc denials with the same permission and the
> same triple across a period of time if the cache entry was evicted in
> between the two avc denials.
> 
> In terms of getting the behavior you want (i.e. see all instances of an
> avc denial), you really only have these choices without modifying code:
> 1) use enforcing mode, or
> 2) set the cache threshold to 1
> 
> Or you could modify the kernel for your development purposes.  It would
> be a pretty trivial patch.  What's your base kernel version?

never tried it, but I think a

auditallow user_t etc_t:file write;

would give you a message every time.   It would be an allow rather than
a deny but does it give you the info you want and wouldn't be nearly the
perf killer threshold to 1 would be....

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Avc denies while running in Permissive mode...

[Eric Paris]

On Wed, 2008-12-17 at 12:42 -0500, Stephen Smalley wrote:
> On Wed, 2008-12-17 at 12:08 -0500, Hasan Rezaul-CHR010 wrote:
> > Hi All,
> > 
> > Lets just say in my product, we are not confident enough to run in
> > Enforcing mode just yet !
> > 
> > I used Fedora Core 7 *strict* policy as my base policy, and built my own
> > additional myModule.pp policies on top of that. So, I have *strict*
> > SELinux policy running on an embedded Linux Card, in Permissive mode.
> > 
> > Due to auto-relabelling of the filesystem, files in the  /etc/
> > directory get appropriately labelled as  etc_t (as desired).
> > 
> > I have myModule.pp policy lines that say :
> > 
> > neverallow user_t etc_t:file write;
> > neverallow user_t etc_t:dir write;
> > 
> > My question is:
> > 
> > When I ssh in as a test user with a security context =
> > [user_u:user_r:user_t], and I attempt to modify/write some file in the
> > /etc/  directory,  I do get an avc deny message in the audit.log file,
> > as desired  :-)
> > 
> > But subsequent attempts to do the same thing doesn't generate any more
> > avc denies ??? In other words, when I attempt to modify the same file
> > again, or modify a different file under /etc/  as the same test user...
> > I DON'T get any more avc deny messages ?!?
> > 
> > I know that if I switch from Permissive to Enforcing mode, I get avc
> > deny msgs for EVERY single violation !
> > 
> > But in Permissive mode, I would like to also get a deny for every
> > violation attempt.. How do I achieve this ?
> > 
> > Because I am running with *strict* policy, during normal operation of my
> > Linux card, I have numerous avc deny messages that pop up from time to
> > time. So I collect all those deny messages, run audit2allow on them, and
> > try to eliminate these denies in the policy.  
> > 
> > But what confuses me is that, there are some avc denies that seem to be
> > about the same operation, and those avc denies keep popping up
> > repeatedly in the Permissive mode... Why then cant the scenario
> > described above produce repeated avc denies ???
> > 
> > I understand that there is a mechanism to prevent flooding of avc denies
> > in Permissive mode. And I did try to change the
> > /selinux/avc/cache_threshold file, by putting a "1" there instead of
> > "512". But doing that causes a lot of CPU to be chewed up by SELinux.   
> > 
> > Any other suggestions for why the scenario I described above, about a
> > test user (user_t), trying to modify multiple files under the /etc/
> > directory creates only one avc deny message, and doesn't generate an avc
> > deny for each attempt ???
> > 
> > Apologize for the long mail. Thanks in advance for your help,
> 
> In permissive mode, when a permission would be denied for a given
> (source context, target context, target class) triple for the first
> time, the kernel audits the denial (avc:  denied) and then adds that
> permission to the allowed vector for that triple in the AVC (access
> vector cache).  Thus, subsequent uses of that same permission on that
> same triple will not trigger further denials until the cache entry is
> evicted from the cache (which can happen automatically if we need to
> free up space for use by other entries or explicitly upon either a
> policy reload or changing a policy boolean).
> 
> So you might for example see avc denials with different permissions on
> the same triple or avc denials with the same permission on different
> triples.  You may also see avc denials with the same permission and the
> same triple across a period of time if the cache entry was evicted in
> between the two avc denials.
> 
> In terms of getting the behavior you want (i.e. see all instances of an
> avc denial), you really only have these choices without modifying code:
> 1) use enforcing mode, or
> 2) set the cache threshold to 1
> 
> Or you could modify the kernel for your development purposes.  It would
> be a pretty trivial patch.  What's your base kernel version?

I also think you could get something like the notification you want
using an audit rule sorta like

auditctl -a exit,always -S write -F subj_type=user_t obj_type=etc_t

again, it's not an AVC denial, but it will tell you ever time the
operation happened....

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Avc denies while running in Permissive mode...

[James Morris]

On Wed, 17 Dec 2008, Stephen Smalley wrote:

> In permissive mode, when a permission would be denied for a given
> (source context, target context, target class) triple for the first
> time, the kernel audits the denial (avc:  denied) and then adds that
> permission to the allowed vector for that triple in the AVC (access
> vector cache).  Thus, subsequent uses of that same permission on that
> same triple will not trigger further denials until the cache entry is
> evicted from the cache (which can happen automatically if we need to
> free up space for use by other entries or explicitly upon either a
> policy reload or changing a policy boolean).

What about adding a kernel option (say, selinux_permissive_debug), which 
causes the permission update to be bypassed, but still allows the 
operation?

Something like:

int avc_has_perm_noaudit(...)
{

	...

        if (denied) {
                if (flags & AVC_STRICT)
                        rc = -EACCES;
                else if (!selinux_enforcing || security_permissive_sid(ssid))
			if (!selinux_permissive_debug)
				avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
                                	        tsid, tclass);
                else
                        rc = -EACCES;
        }

	...
}

-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Avc denies while running in Permissive mode...

[Stephen Smalley]

On Thu, 2008-12-18 at 15:30 +1100, James Morris wrote:
> On Wed, 17 Dec 2008, Stephen Smalley wrote:
> 
> > In permissive mode, when a permission would be denied for a given
> > (source context, target context, target class) triple for the first
> > time, the kernel audits the denial (avc:  denied) and then adds that
> > permission to the allowed vector for that triple in the AVC (access
> > vector cache).  Thus, subsequent uses of that same permission on that
> > same triple will not trigger further denials until the cache entry is
> > evicted from the cache (which can happen automatically if we need to
> > free up space for use by other entries or explicitly upon either a
> > policy reload or changing a policy boolean).
> 
> What about adding a kernel option (say, selinux_permissive_debug), which 
> causes the permission update to be bypassed, but still allows the 
> operation?
> 
> Something like:
> 
> int avc_has_perm_noaudit(...)
> {
> 
> 	...
> 
>         if (denied) {
>                 if (flags & AVC_STRICT)
>                         rc = -EACCES;
>                 else if (!selinux_enforcing || security_permissive_sid(ssid))
> 			if (!selinux_permissive_debug)
> 				avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
>                                 	        tsid, tclass);
>                 else
>                         rc = -EACCES;
>         }
> 
> 	...
> }

Yes, that was what I had in mind, although Eric seems to think we can
get by via existing auditallow and/or syscall audit mechanisms.

Such an option could have its initial value specified via kernel config
or via boot parameter (so that one can boot a kernel in this state
initially and collect all avc messages in permissive) and the value
could subsequently be changed via a new selinuxfs node.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Avc denies while running in Permissive mode...

[Eric Paris]

On Thu, 2008-12-18 at 08:57 -0500, Stephen Smalley wrote:
> On Thu, 2008-12-18 at 15:30 +1100, James Morris wrote:
> > On Wed, 17 Dec 2008, Stephen Smalley wrote:
> > 
> > > In permissive mode, when a permission would be denied for a given
> > > (source context, target context, target class) triple for the first
> > > time, the kernel audits the denial (avc:  denied) and then adds that
> > > permission to the allowed vector for that triple in the AVC (access
> > > vector cache).  Thus, subsequent uses of that same permission on that
> > > same triple will not trigger further denials until the cache entry is
> > > evicted from the cache (which can happen automatically if we need to
> > > free up space for use by other entries or explicitly upon either a
> > > policy reload or changing a policy boolean).
> > 
> > What about adding a kernel option (say, selinux_permissive_debug), which 
> > causes the permission update to be bypassed, but still allows the 
> > operation?
> > 
> > Something like:
> > 
> > int avc_has_perm_noaudit(...)
> > {
> > 
> > 	...
> > 
> >         if (denied) {
> >                 if (flags & AVC_STRICT)
> >                         rc = -EACCES;
> >                 else if (!selinux_enforcing || security_permissive_sid(ssid))
> > 			if (!selinux_permissive_debug)
> > 				avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
> >                                 	        tsid, tclass);
> >                 else
> >                         rc = -EACCES;
> >         }
> > 
> > 	...
> > }
> 
> Yes, that was what I had in mind, although Eric seems to think we can
> get by via existing auditallow and/or syscall audit mechanisms.
> 
> Such an option could have its initial value specified via kernel config
> or via boot parameter (so that one can boot a kernel in this state
> initially and collect all avc messages in permissive) and the value
> could subsequently be changed via a new selinuxfs node.

The only point of this new impossible to find and twittle flag would be
to get notification of what would have been denied.  I think I gave 2
ways to get such notification and you already get one "correct" denial
which audit2allow will be able to translate.  What tools really
differentiate between one denial and 1000?  Setroubleshoot I guess sorta
does...

I know in the past I've wished something like this flag was present, so
I'm not going to stand in the way, but it seems to me like one can
already get the info and we are just cluttering the kernel code so we
can get the same info another way....

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Avc denies while running in Permissive mode...

[Stephen Smalley]

On Thu, 2008-12-18 at 11:21 -0500, Eric Paris wrote:
> On Thu, 2008-12-18 at 08:57 -0500, Stephen Smalley wrote:
> > On Thu, 2008-12-18 at 15:30 +1100, James Morris wrote:
> > > On Wed, 17 Dec 2008, Stephen Smalley wrote:
> > > 
> > > > In permissive mode, when a permission would be denied for a given
> > > > (source context, target context, target class) triple for the first
> > > > time, the kernel audits the denial (avc:  denied) and then adds that
> > > > permission to the allowed vector for that triple in the AVC (access
> > > > vector cache).  Thus, subsequent uses of that same permission on that
> > > > same triple will not trigger further denials until the cache entry is
> > > > evicted from the cache (which can happen automatically if we need to
> > > > free up space for use by other entries or explicitly upon either a
> > > > policy reload or changing a policy boolean).
> > > 
> > > What about adding a kernel option (say, selinux_permissive_debug), which 
> > > causes the permission update to be bypassed, but still allows the 
> > > operation?
> > > 
> > > Something like:
> > > 
> > > int avc_has_perm_noaudit(...)
> > > {
> > > 
> > > 	...
> > > 
> > >         if (denied) {
> > >                 if (flags & AVC_STRICT)
> > >                         rc = -EACCES;
> > >                 else if (!selinux_enforcing || security_permissive_sid(ssid))
> > > 			if (!selinux_permissive_debug)
> > > 				avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
> > >                                 	        tsid, tclass);
> > >                 else
> > >                         rc = -EACCES;
> > >         }
> > > 
> > > 	...
> > > }
> > 
> > Yes, that was what I had in mind, although Eric seems to think we can
> > get by via existing auditallow and/or syscall audit mechanisms.
> > 
> > Such an option could have its initial value specified via kernel config
> > or via boot parameter (so that one can boot a kernel in this state
> > initially and collect all avc messages in permissive) and the value
> > could subsequently be changed via a new selinuxfs node.
> 
> The only point of this new impossible to find and twittle flag would be
> to get notification of what would have been denied.  I think I gave 2
> ways to get such notification and you already get one "correct" denial
> which audit2allow will be able to translate.  What tools really
> differentiate between one denial and 1000?  Setroubleshoot I guess sorta
> does...
> 
> I know in the past I've wished something like this flag was present, so
> I'm not going to stand in the way, but it seems to me like one can
> already get the info and we are just cluttering the kernel code so we
> can get the same info another way....

It would likely help to know why Hasan wants to see every instance of a
given avc denial.  What benefit do you derive from seeing repeated
instances of the same denial, given that they yield the same resulting
allow rules?

If you just want to run through a test sequence multiple times and see
the denials on each run, then you could always just run load_policy
after each run to flush the AVC.

Or is it the fact that you want to see multiple instances of the same
avc denial because they involve different programs and/or files running
in the same domain or labeled with the same type and you are trying to
figure out what new domains/types you need to introduce?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.