SELinux: open perms on sockets, AF_UNIX

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)

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 <[email protected]>

---

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(-)

security/selinux/hooks.c +2 -0

index 51e8c75..984f0af 100644
@@ -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);

security/selinux/include/av_perm_to_string.h +1 -0

index c0c8854..31df1d7 100644
@@ -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")

security/selinux/include/av_perm_to_string.h +0 -0

    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")

security/selinux/include/av_permissions.h +1 -0

index 0ba79fe..d645192 100644
@@ -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

security/selinux/include/av_permissions.h +0 -1

 #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 [email protected] with the words "unsubscribe selinux" without quotes as the message.

Quoted 11 lines

security/selinux/include/av_perm_to_string.h +1 -0

index c0c8854..31df1d7 100644
@@ -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")

security/selinux/include/av_perm_to_string.h line 156

Quoted 6 lines

security/selinux/include/av_perm_to_string.h +1 -0

    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?

Quoted 10 lines · Stephen Smalley

Quoted 10 lines

security/selinux/include/av_perm_to_string.h +1 -0

index c0c8854..31df1d7 100644
@@ -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")

Quoted 8 lines

security/selinux/include/av_perm_to_string.h line 156

Quoted 7 lines

security/selinux/include/av_perm_to_string.h +1 -0

    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 [email protected] with the words "unsubscribe selinux" without quotes as the message.

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,

Quoted 50 lines · 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.

Quoted 6 lines

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?

Quoted 50 lines · 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.

Quoted 6 lines

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?

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).

Quoted 9 lines · Stephen Smalley

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;
        }

	...
}

Quoted 21 lines · James Morris

Quoted 9 lines · Stephen Smalley

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(...)
{

Quoted 15 lines

	...

        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.

Quoted 38 lines · Stephen Smalley

Quoted 21 lines · James Morris

Quoted 9 lines · Stephen Smalley

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(...)
{

Quoted 15 lines

	...

        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;
        }

	...
}

Quoted 7 lines

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....