Re: [PATCH] libselinux: log no default label warning in verbose mode

[Stephen Smalley]

On Sep 12, 2017 12:49 PM, "Christian Göttsche" 
wrote:

> This seems to revert what was an intentional change to avoid noise in
> fixfiles check output. See the mailing list discussions that preceded and
> followed the patch.


In my opinion, it's a helpful noise, which is triggered by an intended
file context `<>`.
Is there any hack to get the old behavior back other than `find /run
-exec restorecon -n {} \;`?


Why is that helpful/useful? It seems counterintuitive to warn the user that
you didn't label a file that was explicitly configured to not be labeled.
The only case where it makes sense is if the user explicitly requested to
label that particular file.

Re: [PATCH] libselinux: log no default label warning in verbose mode

[Christian Göttsche]

> This seems to revert what was an intentional change to avoid noise in
> fixfiles check output. See the mailing list discussions that preceded and
> followed the patch.


In my opinion, it's a helpful noise, which is triggered by an intended
file context `<>`.
Is there any hack to get the old behavior back other than `find /run
-exec restorecon -n {} \;`?

Re: [GIT PULL] SELinux patches for v4.14

[Linus Torvalds]

On Tue, Sep 12, 2017 at 10:33 AM, Paul Moore  wrote:
> As discussed on the linux-security pull request thread, this is the
> direct SELinux pull request; the content/tag is the same as what I
> sent to James/linux-security earlier:

The contents may be the same, but the base is different.

In particular, you based it on the security tree that already had a
few other patches, so now that branch contains not just selinux work,
but also a couple of tomoyo patches that came in that way.

Anyway, I pulled this simply because it was easier to review and
didn't have anything I disliked per se, but if we're going to actually
keep the different securlty layers separate, they need to also have
clean bases for the work in the future.

Anyway, I'm at the airport on my way back home, and hopefully I'll be
back to normal tomorrow after a good night's sleep, and I can take a
look at the rest.

Linus

Re: with extended_socket_class should be still be seeing "socket"?

[Paul Moore]

On Tue, Sep 12, 2017 at 1:36 PM, Dominick Grift  wrote:
> On Tue, Sep 12, 2017 at 12:01:35PM -0400, Stephen Smalley wrote:
>> On Sep 12, 2017 7:01 AM, "Dominick Grift"  wrote:
>>
>> I have extended socket class polcap enabled but i am still seeing "socket"
>> class events and i was wondering whether that is to be expected?
>>
>> avc:  denied  { create } for  pid=10484 comm="nethogs" scontext=wheel.id:
>> sysadm.role:nethogs.subj:s0 tcontext=wheel.id:sysadm.role:nethogs.subj:s0
>> tclass=socket permissive=0
>>
>> This seems to be common to processes that also create (and map! [1])
>> "packet_socket" sockets (tcpdump/nethogs)
>>
>> [1] avc:  denied  { map } for  pid=10525 comm="nethogs"
>> path="socket:[56040]" dev="sockfs" ino=56040
>> scontext=wheel.id:sysadm.role:nethogs.subj:s0
>> tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=packet_socket
>> permissive=0
>>
>>
>> No, that is not expected. Can you enable sys call audit and get those
>> records?
>
> type=PROCTITLE msg=audit(09/12/2017 19:35:54.063:4458) : proctitle=nethogs 
> enp8s0
> type=SYSCALL msg=audit(09/12/2017 19:35:54.063:4458) : arch=x86_64 
> syscall=socket success=yes exit=5 a0=local a1=SOCK_RAW a2=ip a3=0xb4 items=0 
> ppid=3251 pid=8963 auid=kcinimod uid=root gid=root euid=root suid=root 
> fsuid=root egid=root sgid=root fsgid=root tty=pts5 ses=1 comm=nethogs 
> exe=/usr/sbin/nethogs subj=wheel.id:sysadm.role:nethogs.subj:s0 key=(null)
> type=AVC msg=audit(09/12/2017 19:35:54.063:4458) : avc:  denied  { create } 
> for  pid=8963 comm=nethogs scontext=wheel.id:sysadm.role:nethogs.subj:s0 
> tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=socket permissive=1

Ah ha, AF_UNIX/SOCK_RAW, that's the problem.  Luis Ressel fixed this
(see the commit below) and it should make it up to Linus during the
current merge window (eventually, maybe, hopefully).

If you run Fedora Rawhide, you can try one of recent kernel builds in
the COPR repo below, it should have the fix.

*  https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext

  commit 2a764b529ae57bed61da2c90ff132b9fec97f80b
  Author: Luis Ressel 
  Date:   Tue Jul 25 15:13:41 2017 -0400

   selinux: Assign proper class to PF_UNIX/SOCK_RAW sockets

   For PF_UNIX, SOCK_RAW is synonymous with SOCK_DGRAM (cf.
   net/unix/af_unix.c). This is a tad obscure, but libpcap uses it.

   Signed-off-by: Luis Ressel 
   Acked-by: Stephen Smalley 
   Signed-off-by: Paul Moore 

-- 
paul moore
www.paul-moore.com

[GIT PULL] SELinux patches for v4.14

[Paul Moore]

As discussed on the linux-security pull request thread, this is the
direct SELinux pull request; the content/tag is the same as what I
sent to James/linux-security earlier:

"A relatively quiet period for SELinux, 11 patches with only two/three
 having any substantive changes.  These noteworthy changes include
 another tweak to the NNP/nosuid handling, per-file labeling for
 cgroups, and an object class fix for AF_UNIX/SOCK_RAW sockets; the
 rest of the changes are minor tweaks or administrative updates
 (Stephen's email update explains the file explosion in the diffstat).
 Everything passes the selinux-testsuite and merged cleanly on top of
 the linux-security/next branch from earlier today."

---
The following changes since commit 31368ce83c59a5422ee621a38aeea98142d0ecf7:

 tomoyo: Update URLs in Documentation/admin-guide/LSM/tomoyo.rst
  (2017-07-25 11:00:26 +1000)

are available in the git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
  tags/selinux-pr-20170831

for you to fetch changes up to 0c3014f22dec0e1d14c8298551bfb6434638bdd9:

 selinux: constify nf_hook_ops (2017-08-28 17:33:19 -0400)


selinux/stable-4.14 PR 20170831


Antonio Murdaca (1):
 selinux: allow per-file labeling for cgroupfs

Arvind Yadav (1):
 selinux: constify nf_hook_ops

Luis Ressel (1):
 selinux: Assign proper class to PF_UNIX/SOCK_RAW sockets

Michal Hocko (1):
 selinux: use GFP_NOWAIT in the AVC kmem_caches

Paul Moore (3):
 credits: update Paul Moore's info
 selinux: update the selinux info in MAINTAINERS
 MAINTAINERS: update the NetLabel and Labeled Networking information

Stephen Smalley (4):
 selinux: genheaders should fail if too many permissions are defined
 selinux: Generalize support for NNP/nosuid SELinux domain transitions
 selinux: update my email address
 lsm_audit: update my email address

CREDITS |  8 ++---
MAINTAINERS | 29 ++---
include/linux/lsm_audit.h   |  2 +-
scripts/selinux/genheaders/genheaders.c |  7 -
security/lsm_audit.c|  2 +-
security/selinux/avc.c  | 16 +-
security/selinux/hooks.c| 56 -
security/selinux/include/avc.h  |  2 +-
security/selinux/include/avc_ss.h   |  2 +-
security/selinux/include/classmap.h |  2 ++
security/selinux/include/objsec.h   |  2 +-
security/selinux/include/security.h |  4 ++-
security/selinux/ss/avtab.c |  2 +-
security/selinux/ss/avtab.h |  2 +-
security/selinux/ss/constraint.h|  2 +-
security/selinux/ss/context.h   |  2 +-
security/selinux/ss/ebitmap.c   |  2 +-
security/selinux/ss/ebitmap.h   |  2 +-
security/selinux/ss/hashtab.c   |  2 +-
security/selinux/ss/hashtab.h   |  2 +-
security/selinux/ss/mls.c   |  2 +-
security/selinux/ss/mls.h   |  2 +-
security/selinux/ss/mls_types.h |  2 +-
security/selinux/ss/policydb.c  |  2 +-
security/selinux/ss/policydb.h  |  2 +-
security/selinux/ss/services.c  |  9 --
security/selinux/ss/services.h  |  2 +-
security/selinux/ss/sidtab.c|  2 +-
security/selinux/ss/sidtab.h|  2 +-
security/selinux/ss/symtab.c|  2 +-
security/selinux/ss/symtab.h|  2 +-
31 files changed, 106 insertions(+), 71 deletions(-)

-- 
paul moore
www.paul-moore.com

Re: with extended_socket_class should be still be seeing "socket"?

[Dominick Grift]

On Tue, Sep 12, 2017 at 12:01:35PM -0400, Stephen Smalley wrote:
> On Sep 12, 2017 7:01 AM, "Dominick Grift"  wrote:
> 
> I have extended socket class polcap enabled but i am still seeing "socket"
> class events and i was wondering whether that is to be expected?
> 
> avc:  denied  { create } for  pid=10484 comm="nethogs" scontext=wheel.id:
> sysadm.role:nethogs.subj:s0 tcontext=wheel.id:sysadm.role:nethogs.subj:s0
> tclass=socket permissive=0
> 
> This seems to be common to processes that also create (and map! [1])
> "packet_socket" sockets (tcpdump/nethogs)
> 
> [1] avc:  denied  { map } for  pid=10525 comm="nethogs"
> path="socket:[56040]" dev="sockfs" ino=56040
> scontext=wheel.id:sysadm.role:nethogs.subj:s0
> tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=packet_socket
> permissive=0
> 
> 
> No, that is not expected. Can you enable sys call audit and get those
> records?

type=PROCTITLE msg=audit(09/12/2017 19:35:54.063:4458) : proctitle=nethogs 
enp8s0 
type=SYSCALL msg=audit(09/12/2017 19:35:54.063:4458) : arch=x86_64 
syscall=socket success=yes exit=5 a0=local a1=SOCK_RAW a2=ip a3=0xb4 items=0 
ppid=3251 pid=8963 auid=kcinimod uid=root gid=root euid=root suid=root 
fsuid=root egid=root sgid=root fsgid=root tty=pts5 ses=1 comm=nethogs 
exe=/usr/sbin/nethogs subj=wheel.id:sysadm.role:nethogs.subj:s0 key=(null) 
type=AVC msg=audit(09/12/2017 19:35:54.063:4458) : avc:  denied  { create } for 
 pid=8963 comm=nethogs scontext=wheel.id:sysadm.role:nethogs.subj:s0 
tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=socket permissive=1

type=PROCTITLE msg=audit(09/12/2017 19:35:07.983:4457) : proctitle=nethogs 
enp8s0 
type=MMAP msg=audit(09/12/2017 19:35:07.983:4457) : fd=5 flags=MAP_SHARED 
type=SYSCALL msg=audit(09/12/2017 19:35:07.983:4457) : arch=x86_64 syscall=mmap 
success=yes exit=140169557827584 a0=0x0 a1=0x20 a2=PROT_READ|PROT_WRITE 
a3=MAP_SHARED items=0 ppid=3251 pid=8907 auid=kcinimod uid=root gid=root 
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts5 ses=1 
comm=nethogs exe=/usr/sbin/nethogs subj=wheel.id:sysadm.role:nethogs.subj:s0 
key=(null) 
type=AVC msg=audit(09/12/2017 19:35:07.983:4457) : avc:  denied  { map } for  
pid=8907 comm=nethogs path=socket:[103238] dev="sockfs" ino=103238 
scontext=wheel.id:sysadm.role:nethogs.subj:s0 
tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=packet_socket permissive=1

> 
> 
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature

Re: [PATCH] libselinux: log no default label warning in verbose mode

[Stephen Smalley]

On Sep 11, 2017 3:45 AM, "Christian Göttsche via Selinux" <
selinux@tycho.nsa.gov> wrote:

Since 1cd972f restorecon does not print a warning in recurse mode for child
files without a default label.
Change it back in verbose mode:

$ touch /run/test.pid
$ restorecon -R /run
$ restorecon -v -R /run
Warning no default label for /run/test.pid


This seems to revert what was an intentional change to avoid noise in
fixfiles check output. See the mailing list discussions that preceded and
followed the patch.


Signed-off-by: Christian Göttsche 
---
 libselinux/src/selinux_restorecon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libselinux/src/selinux_restorecon.c b/libselinux/src/selinux_
restorecon.c
index ced41152..6d0eabe0 100644
--- a/libselinux/src/selinux_restorecon.c
+++ b/libselinux/src/selinux_restorecon.c
@@ -614,7 +614,7 @@ static int restorecon_sb(const char *pathname, const
struct stat *sb,
sb->st_mode);

if (rc < 0) {
-   if (errno == ENOENT && flags->warnonnomatch)
+   if (errno == ENOENT && (flags->verbose ||
flags->warnonnomatch))
selinux_log(SELINUX_INFO,
"Warning no default label for %s\n",
lookup_path);
--
2.14.1

Re: with extended_socket_class should be still be seeing "socket"?

[Stephen Smalley]

On Sep 12, 2017 7:01 AM, "Dominick Grift"  wrote:

I have extended socket class polcap enabled but i am still seeing "socket"
class events and i was wondering whether that is to be expected?

avc:  denied  { create } for  pid=10484 comm="nethogs" scontext=wheel.id:
sysadm.role:nethogs.subj:s0 tcontext=wheel.id:sysadm.role:nethogs.subj:s0
tclass=socket permissive=0

This seems to be common to processes that also create (and map! [1])
"packet_socket" sockets (tcpdump/nethogs)

[1] avc:  denied  { map } for  pid=10525 comm="nethogs"
path="socket:[56040]" dev="sockfs" ino=56040
scontext=wheel.id:sysadm.role:nethogs.subj:s0
tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=packet_socket
permissive=0


No, that is not expected. Can you enable sys call audit and get those
records?


--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift

Re: Userspace Python version

[Stephen Smalley]

On Sep 8, 2017 6:49 PM, "Chris PeBenito"  wrote:

I believe that all major SELinux distributions have at least Python 3.4
support.  Python 3 changeover has gone so long that even 3.3 is about to go
end-of-life [1].  Can we officially drop Python 2.7 support in userspace
code?

I'd like to drop support for everything older than Python 3.4 in SETools.

[1] http://blog.python.org/2017/09/python-337rc1-is-now-availabl
e-prior-to.html


I would be fine with doing so.

with extended_socket_class should be still be seeing "socket"?

[Dominick Grift]

I have extended socket class polcap enabled but i am still seeing "socket" 
class events and i was wondering whether that is to be expected?

avc:  denied  { create } for  pid=10484 comm="nethogs" 
scontext=wheel.id:sysadm.role:nethogs.subj:s0 
tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=socket permissive=0

This seems to be common to processes that also create (and map! [1]) 
"packet_socket" sockets (tcpdump/nethogs)

[1] avc:  denied  { map } for  pid=10525 comm="nethogs" path="socket:[56040]" 
dev="sockfs" ino=56040 scontext=wheel.id:sysadm.role:nethogs.subj:s0 
tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=packet_socket permissive=0

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature