Re: Fwd: Qwery regarding Selinux Change Id context

[Stephen Smalley]

On Wed, 2017-11-29 at 21:39 +0530, Aman Sharma wrote:
> Hi Stephen,
> 
> After enabling the unconfined module and after reboot also, Still
> showing the same id context.
> 
> Is there any way to make the id context to normal state again ? 

Hmmm...try resetting all booleans too?  semanage boolean -D

Or you could be drastic and completely reset your policy:
mv /etc/selinux/targeted /etc/selinux/targeted.old
yum reinstall selinux-policy-targeted

Re: Fwd: Qwery regarding Selinux Change Id context

[Stephen Smalley]

On Wed, 2017-11-29 at 22:01 +0530, Aman Sharma wrote:
> After resetting boolean also, showing the same id context.

And did you try fully resetting your policy as I suggested:
mv /etc/selinux/targeted /etc/selinux/targeted.old
yum reinstall selinux-policy-targeted
reboot

> 
> 
> On Wed, Nov 29, 2017 at 9:50 PM, Stephen Smalley <s...@tycho.nsa.gov>
> wrote:
> > On Wed, 2017-11-29 at 21:39 +0530, Aman Sharma wrote:
> > > Hi Stephen,
> > >
> > > After enabling the unconfined module and after reboot also, Still
> > > showing the same id context.
> > >
> > > Is there any way to make the id context to normal state again ? 
> > 
> > Hmmm...try resetting all booleans too?  semanage boolean -D
> > 
> > Or you could be drastic and completely reset your policy:
> > mv /etc/selinux/targeted /etc/selinux/targeted.old
> > yum reinstall selinux-policy-targeted
> > 
> 
> 
> 
> -- 
> 
> Thanks
> Aman
> Cell: +91 9990296404 |  Email ID : amansh.shar...@gmail.com

Re: KASAN: slab-out-of-bounds Read in strcmp

[Stephen Smalley]

On Mon, 2017-12-04 at 17:39 +0100, Dmitry Vyukov wrote:
> On Mon, Dec 4, 2017 at 2:59 PM, Paul Moore  wrote:
> > > > > On 2017/12/02 3:52, syzbot wrote:
> > > > > > ===
> > > > > > ===
> > > > > > BUG: KASAN: slab-out-of-bounds in strcmp+0x96/0xb0
> > > > > > lib/string.c:328
> > > > > > Read of size 1 at addr 8801cd99d2c1 by task
> > > > > > syzkaller242593/3087
> > > > > > 
> > > > > > CPU: 0 PID: 3087 Comm: syzkaller242593 Not tainted 4.15.0-
> > > > > > rc1-next-
> > > > > > 20171201+ #57
> > > > > > Hardware name: Google Google Compute Engine/Google Compute
> > > > > > Engine,
> > > > > > BIOS Google 01/01/2011
> > > > > > Call Trace:
> > > > > >  __dump_stack lib/dump_stack.c:17 [inline]
> > > > > >  dump_stack+0x194/0x257 lib/dump_stack.c:53
> > > > > >  print_address_description+0x73/0x250 mm/kasan/report.c:252
> > > > > >  kasan_report_error mm/kasan/report.c:351 [inline]
> > > > > >  kasan_report+0x25b/0x340 mm/kasan/report.c:409
> > > > > >  __asan_report_load1_noabort+0x14/0x20
> > > > > > mm/kasan/report.c:427
> > > > > >  strcmp+0x96/0xb0 lib/string.c:328
> > > > > 
> > > > > This seems to be out of bound read for "scontext" at
> > > > > 
> > > > >   for (i = 1; i < SECINITSID_NUM; i++) {
> > > > >   if (!strcmp(initial_sid_to_string[i],
> > > > > scontext)) {
> > > > >   *sid = i;
> > > > >   return 0;
> > > > >   }
> > > > >   }
> > > > > 
> > > > > because "initial_sid_to_string[i]" is "const char *".
> > > > > 
> > > > > >  security_context_to_sid_core+0x437/0x620
> > > > > > security/selinux/ss/services.c:1420
> > > > > >  security_context_to_sid+0x32/0x40
> > > > > > security/selinux/ss/services.c:1479
> > > > > >  selinux_setprocattr+0x51c/0xb50
> > > > > > security/selinux/hooks.c:5986
> > > > > >  security_setprocattr+0x85/0xc0 security/security.c:1264
> > > > > 
> > > > > If "value" does not terminate with '\0' or '\n', "value" and
> > > > > "size" are as-is passed to "scontext" and "scontext_len"
> > > > > above
> > > > > 
> > > > >   /* Obtain a SID for the context, if one was specified.
> > > > > */
> > > > >   if (size && str[0] && str[0] != '\n') {
> > > > >   if (str[size-1] == '\n') {
> > > > >   str[size-1] = 0;
> > > > >   size--;
> > > > >   }
> > > > >   error = security_context_to_sid(value, size,
> > > > > ,
> > > > > GFP_KERNEL);
> > > > > 
> > > > > which will allow strcmp() to trigger out of bound read when
> > > > > "size" is
> > > > > larger than strlen(initial_sid_to_string[i]).
> > > > > 
> > > > > Thus, I guess the simplest fix is to use strncmp() instead of
> > > > > strcmp().
> > > > 
> > > > Already fixed by
> > > > https://www.spinics.net/lists/selinux/msg23589.html
> > > 
> > > 
> > > Paul, please also follow this part:
> > > 
> > > > syzbot will keep track of this bug report.
> > > > Once a fix for this bug is committed, please reply to this
> > > > email with:
> > > > #syz fix: exact-commit-title
> > > > Note: all commands must start from beginning of the line in the
> > > > email body.
> > > 
> > > This will greatly help to keep overall process running. Thanks.
> > 
> > When is the right time to do this?  The text say to reply when a
> > patch
> > has been committed, but where?  My selinux/next branch?  Linus'
> > master?  Your docs and the end of the email needs to be more clear
> > on
> > this.
> > 
> > For the record, I did see that part of the syzbot mail but I was
> > waiting until I merged that patch; v2 was posted late in the week
> > and
> > I was giving it a few days in case someone saw something
> > objectionable.
> > 
> > Also, while we are on the topic of syzbot, what SELinux policy (if
> > any) do you load on the system that is undergoing testing?  Based
> > on
> > some of the recent reports it would appear that you are running a
> > SELinux enabled kernel but might not be loading a SELinux policy,
> > is
> > that correct?
> 
> 
> This is good question. The problem is that we are testing almost all
> kernel subsystems, but are not experts in most of them. So frequently
> we doing some non-sense. And that's where we need you help.
> That's what we have for grep SECURITY .config:
> 
> CONFIG_EXT4_FS_SECURITY=y
> # CONFIG_9P_FS_SECURITY is not set
> # CONFIG_SECURITY_DMESG_RESTRICT is not set
> CONFIG_SECURITY=y
> CONFIG_SECURITY_WRITABLE_HOOKS=y
> # CONFIG_SECURITYFS is not set
> CONFIG_SECURITY_NETWORK=y
> CONFIG_SECURITY_NETWORK_XFRM=y
> CONFIG_SECURITY_PATH=y
> CONFIG_SECURITY_SELINUX=y
> CONFIG_SECURITY_SELINUX_BOOTPARAM=y
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
> CONFIG_SECURITY_SELINUX_DISABLE=y
> CONFIG_SECURITY_SELINUX_DEVELOP=y
> CONFIG_SECURITY_SELINUX_AVC_STATS=y
> CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0
> # CONFIG_SECURITY_SMACK is not set
> # CONFIG_SECURITY_TOMOYO is not set
> # 

Re: [PATCH] selinux: ensure the context is NULL terminated in security_context_to_sid_core()

[Stephen Smalley]

On Fri, 2017-12-01 at 10:34 -0500, Paul Moore wrote:
> On Thu, Nov 30, 2017 at 6:44 PM, William Roberts
>  wrote:
> > On Thu, Nov 30, 2017 at 8:52 AM, Paul Moore 
> > wrote:
> > > From: Paul Moore 
> > > 
> > > The syzbot/syzkaller automated tests found a problem in
> > > security_context_to_sid_core() during early boot (before we load
> > > the
> > > SELinux policy) where we could potentially feed context strings
> > > without
> > > NULL terminators into the strcmp() function.
> > > 
> > > We already guard against this during normal operation (after the
> > > SELinux
> > > policy has been loaded) by making a copy of the context strings
> > > and
> > > explicitly adding a NULL terminator to the end.  The patch
> > > extends this
> > > protection to the early boot case (no loaded policy) by moving
> > > the context
> > > copy earlier in security_context_to_sid_core().
> > > 
> > > Reported-by: syzbot 
> > > Signed-off-by: Paul Moore 
> > > ---
> > >  security/selinux/ss/services.c |   20 ++--
> > >  1 file changed, 10 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/security/selinux/ss/services.c
> > > b/security/selinux/ss/services.c
> > > index 33cfe5d3d6cb..6ec4cdc8af8f 100644
> > > --- a/security/selinux/ss/services.c
> > > +++ b/security/selinux/ss/services.c
> > > @@ -1413,27 +1413,27 @@ static int
> > > security_context_to_sid_core(const char *scontext, u32
> > > scontext_len,
> > > if (!scontext_len)
> > > return -EINVAL;
> > > 
> > > +   /* Copy the string to allow changes and ensure a NULL
> > > terminator */
> > > +   scontext2 = kmalloc(scontext_len + 1, gfp_flags);
> > > +   if (!scontext2)
> > > +   return -ENOMEM;
> > > +   memcpy(scontext2, scontext, scontext_len);
> > > +   scontext2[scontext_len] = 0;
> > 
> > Call me crazy, but can't we use kmemdup_nul() here?
> 
> Crazy good idea ;)
> 
> I didn't realize that function existed, I'll respin.  Thanks.

Also note that it should be NUL not NULL in the patch subject and
description.  '\0' vs (void*)0

> 
> > /**
> >  * kmemdup_nul - Create a NUL-terminated string from unterminated
> > data
> >  * @s: The data to stringify
> >  * @len: The size of the data
> >  * @gfp: the GFP mask used in the kmalloc() call when allocating
> > memory
> >  */
> > char *kmemdup_nul(const char *s, size_t len, gfp_t gfp)
> 
> 

Re: Qwery regarding Selinux Change Id context

[Stephen Smalley]

On Fri, 2017-12-01 at 14:16 -0500, Simon Sekidde wrote:
> 
> - Original Message -
> > From: "Aman Sharma" <amansh.shar...@gmail.com>
> > To: "SELinux" <selinux@tycho.nsa.gov>
> > Sent: Thursday, November 30, 2017 11:26:21 PM
> > Subject: Re: Fwd: Qwery regarding Selinux Change Id context
> > 
> > Hi ,
> > 
> > mv /var/lib/selinux/targeted /var/lib/selinux/targeted.old
> > 
> > This targeted folder is not there.
> > 
> > After searching I got the below result :
> > 
> > find / -type d -name "*targeted" -print
> > 
> > /usr/share/selinux/targeted
> > /etc/selinux/targeted
> > 
> > Pleas let me know your comments.
> > 
> 
> Run
> 
> mv /etc/selinux/targeted /etc/selinux/targeted.old 
> yum reinstall selinux-policy-targeted

He already tried that and it allegedly didn't help.  It also seems to
leave you without a /etc/selinux/targeted/active/seusers file for some
reason, such that semanage login -l shows nothing.  But you can recover
by copying /etc/selinux/targeted/seusers to
/etc/selinux/targeted/active/seusers.  That's a bug.

> 
> Also what does this output show 
> 
> ps -aelfZ | grep -i ssh 
> 
> > 
> > On Fri, Dec 1, 2017 at 1:49 AM, Dominick Grift <dac.override@gmail.
> > com>
> > wrote:
> > 
> > > On Thu, Nov 30, 2017 at 11:10:43AM +0530, Aman Sharma wrote:
> > > > Hi Stephen,
> > > > 
> > > > After reseting Selinux targeted folder also (the steps you
> > > > mentioned in
> > > 
> > > the
> > > > earlier mail), Still its showing the same Id context i.e.
> > > > 
> > > > *id*
> > > > *uid=0(root) gid=0(root) groups=0(root)
> > > > context=system_u:system_r:unconfined_t:s0-s0:c0.c1023*
> > > > *[root@cucm2 ~]# id -Z*
> > > > *system_u:system_r:unconfined_t:s0-s0:c0.c1023*
> > > > 
> > > > *And semanage login -l is showing blank output. *
> > > > 
> > > > *Do you have any idea about this.*
> > > > 
> > > > *Thanks*
> > > > *Aman*
> > > 
> > > Try the same procedure again but this time also do before
> > > reinstalling:
> > > 
> > > mv /var/lib/selinux/targeted /var/lib/selinux/targeted.old
> > > 
> > > > 
> > > > 
> > > > On Wed, Nov 29, 2017 at 11:04 PM, Stephen Smalley <s...@tycho.ns
> > > > a.gov>
> > > 
> > > wrote:
> > > > 
> > > > > On Wed, 2017-11-29 at 22:01 +0530, Aman Sharma wrote:
> > > > > > After resetting boolean also, showing the same id context.
> > > > > 
> > > > > And did you try fully resetting your policy as I suggested:
> > > > > mv /etc/selinux/targeted /etc/selinux/targeted.old
> > > > > yum reinstall selinux-policy-targeted
> > > > > reboot
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, Nov 29, 2017 at 9:50 PM, Stephen Smalley <sds@tycho
> > > > > > .nsa.gov>
> > > > > > wrote:
> > > > > > > On Wed, 2017-11-29 at 21:39 +0530, Aman Sharma wrote:
> > > > > > > > Hi Stephen,
> > > > > > > > 
> > > > > > > > After enabling the unconfined module and after reboot
> > > > > > > > also, Still
> > > > > > > > showing the same id context.
> > > > > > > > 
> > > > > > > > Is there any way to make the id context to normal state
> > > > > > > > again ?
> > > > > > > 
> > > > > > > Hmmm...try resetting all booleans too?  semanage boolean
> > > > > > > -D
> > > > > > > 
> > > > > > > Or you could be drastic and completely reset your policy:
> > > > > > > mv /etc/selinux/targeted /etc/selinux/targeted.old
> > > > > > > yum reinstall selinux-policy-targeted
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > 
> > > > > > Thanks
> > > > > > Aman
> > > > > > Cell: +91 9990296404 |  Email ID : amansh.shar...@gmail.com
> > > > 
> > > > 
> > > > 
> > > > --
> > > > 
> > > > Thanks
> > > > Aman
> > > > Cell: +91 9990296404 |  Email ID : amansh.shar...@gmail.com
> > > 
> > > --
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> > > 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7
> > > B6B02
> > > Dominick Grift
> > > 
> > 
> > 
> > 
> > --
> > 
> > Thanks
> > Aman
> > Cell: +91 9990296404 |  Email ID : amansh.shar...@gmail.com
> > 
> 
> 

Re: [BUG]kernel softlockup due to sidtab_search_context run for long time because of too many sidtab context node

[Stephen Smalley]

On Thu, 2017-12-14 at 03:19 +, yangjihong wrote:
> Hello,
> 
> >  So, does docker just keep allocating a unique category set for
> > every new container, never reusing them even if the container is
> > destroyed? 
> >  That would be a bug in docker IMHO.  Or are you creating an
> > unbounded number of containers and never destroying the older ones?
> 
> I creat a containers, then destroy it,  and create second one,
> destroy it...
> When docker created, it will mount overlay fs, because every
> containers has different selinux context, so a new sidtab node is
> generated and insert into the sidtab list  
> When docker destroyed, it will umount overlay fs, but umount
> operation does not seem relevant to "delete the node" hooks function,
> resulting in longer and longer sidtab list
> I think when umount, its selinux context will never reuse, so sidtab
> node is useless, it is best to delete i

The "selinux context will never reuse" is IMHO a bug in docker; if you
truly destroy the container (i.e. don't just stop its execution, but
delete it entirely), then the context should be reusable.

> >  sidtab_search_context() could no doubt be optimized for the
> > negative case; there was an earlier optimization for the positive
> > case by adding a cache to sidtab_context_to_sid() prior to calling
> > it.  It's a reverse lookup in the sidtab.
> 
> I think add cache may be not very userful, because every containers
> has different selinux context, so when one docker created, it will
> search the whole sidtab list, until compare the last node, When a new
> node arrives, it is always necessary to compare all the nodes first,
> and then insert. 
> All as long as the list does not delete the node, list will always
> increase, and search time will longer and longer, eventually leading
> to softlockup
> 
> 
> Is there any solution to this problem?

On the kernel side, we could certainly implement a reverse lookup hash
table.  And there could be a faster way to quickly check whether a
given category set has ever been used if we wanted to specialize in
that manner.  But that won't fix the fact that docker is allocating
unbounded security contexts.

Re: PAM Security related issue

[Stephen Smalley]

On Thu, 2017-12-14 at 12:48 +0530, Aman Sharma wrote:
> Hi All,
> 
> Below is the output of semanage USer command output for sftpuser:
> 
> specialuser_u   user       s0         s0                           
>  sysadm_r system_r
> 
> and for command semanage login -l , output is :
> 
> sftpuser             specialuser_u        s0                   *
> 
> and also, after adding the debugging option, its showing the below
> error message as 
> 
> Dec 13 15:46:10 cucmSUB authpriv 3 sshd: pam_selinux(sshd:session):
> Unable to get valid context for sftpuser
> Dec 13 15:46:10 cucmSUB authpriv 5 sshd: pam_selinux(sshd:session):
> Open Session
> Dec 13 15:46:11 cucmSUB authpriv 7 sshd: pam_selinux(sshd:session):
> Username= sftpuser SELinux User= specialuser_u Level= s0
> Dec 13 15:46:11 cucmSUB authpriv 3 sshd: pam_selinux(sshd:session):
> Unable to get valid context for sftpuser
> 
> also Selinuxdefcon command is showing error while running for
> sftpuser i.e. 
> sudo /usr/sbin/selinuxdefcon sftpuser system_u:system_r:sshd_t:s0
> /usr/sbin/selinuxdefcon: Invalid argument
> 
> Please let me know your comments on this.

Is there a reason why you've added your own unique SELinux user and
login entries for sftpuser rather than either just mapping to one of
the existing users if you want it to be confined or leaving it
unspecified and just using the __default__ entry if you want it to be
unconfined?

The entries above say that sftpuser is to be mapped to specialuser_u,
and that specialuser_u can only use the sysadm_r or system_r roles.  To
make that work, you would also need to enable the ssh_sysadm_login
boolean and cp /etc/selinux/targeted/contexts/users/sysadm_u
/etc/selinux/targeted/contexts/users/specialuser_u.  But that seems
pointless since you could just leave it unmapped or map it to sysadm_u
in the first place if that was really what you wanted.

If you want sftpuser to be unrestricted, just remove the mappings, i.e.
$ sudo semanage login -d sftpuser
$ sudo semanage user -d specialuser_u
$ selinuxdefcon sftpuser system_u:system_r:sshd_t:s0-s0:c0.c1023
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Re: [BUG]kernel softlockup due to sidtab_search_context run for long time because of too many sidtab context node

[Stephen Smalley]

On Thu, 2017-12-14 at 08:18 -0800, Casey Schaufler wrote:
> On 12/13/2017 7:18 AM, Stephen Smalley wrote:
> > On Wed, 2017-12-13 at 09:25 +, yangjihong wrote:
> > > Hello, 
> > > 
> > > I am doing stressing testing on 3.10 kernel(centos 7.4), to
> > > constantly starting numbers of docker ontainers with selinux
> > > enabled,
> > > and after about 2 days, the kernel softlockup panic:
> > >    [] sched_show_task+0xb8/0x120
> > >  [] show_lock_info+0x20f/0x3a0
> > >  [] watchdog_timer_fn+0x1da/0x2f0
> > >  [] ? watchdog_enable_all_cpus.part.4+0x40/0x40
> > >  [] __hrtimer_run_queues+0xd2/0x260
> > >  [] hrtimer_interrupt+0xb0/0x1e0
> > >  [] local_apic_timer_interrupt+0x37/0x60
> > >  [] smp_apic_timer_interrupt+0x50/0x140
> > >  [] apic_timer_interrupt+0x6d/0x80
> > >    [] ? sidtab_context_to_sid+0xb3/0x480
> > >  [] ? sidtab_context_to_sid+0x110/0x480
> > >  [] ? mls_setup_user_range+0x145/0x250
> > >  [] security_get_user_sids+0x3f7/0x550
> > >  [] sel_write_user+0x12b/0x210
> > >  [] ? sel_write_member+0x200/0x200
> > >  [] selinux_transaction_write+0x48/0x80
> > >  [] vfs_write+0xbd/0x1e0
> > >  [] SyS_write+0x7f/0xe0
> > >  [] system_call_fastpath+0x16/0x1b
> > > 
> > > My opinion:
> > > when the docker container starts, it would mount overlay
> > > filesystem
> > > with different selinux context, mount point such as: 
> > > overlay on
> > > /var/lib/docker/overlay2/be3ef517730d92fc4530e0e952eae4f6cb0f07b4
> > > bc32
> > > 6cb07495ca08fc9ddb66/merged type overlay
> > > (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:s0:c
> > > 414,
> > > c873",lowerdir=/var/lib/docker/overlay2/l/Z4U7WY6ASNV5CFWLADPARHH
> > > WY7:
> > > /var/lib/docker/overlay2/l/V2S3HOKEFEOQLHBVAL5WLA3YLS:/var/lib/do
> > > cker
> > > /overlay2/l/46YGYO474KLOULZGDSZDW2JPRI,upperdir=/var/lib/docker/o
> > > verl
> > > ay2/be3ef517730d92fc4530e0e952eae4f6cb0f07b4bc326cb07495ca08fc9dd
> > > b66/
> > > diff,workdir=/var/lib/docker/overlay2/be3ef517730d92fc4530e0e952e
> > > ae4f
> > > 6cb0f07b4bc326cb07495ca08fc9ddb66/work)
> > > shm on
> > > /var/lib/docker/containers/9fd65e177d2132011d7b422755793449c91327
> > > ca57
> > > 7b8f5d9d6a4adf218d4876/shm type tmpfs
> > > (rw,nosuid,nodev,noexec,relatime,context="system_u:object_r:svirt
> > > _san
> > > dbox_file_t:s0:c414,c873",size=65536k)
> > > overlay on
> > > /var/lib/docker/overlay2/38d1544d080145c7d76150530d0255991dfb7258
> > > cbca
> > > 14ff6d165b94353eefab/merged type overlay
> > > (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:s0:c
> > > 431,
> > > c651",lowerdir=/var/lib/docker/overlay2/l/3MQQXB4UCLFB7ANVRHPAVRC
> > > RSS:
> > > /var/lib/docker/overlay2/l/46YGYO474KLOULZGDSZDW2JPRI,upperdir=/v
> > > ar/l
> > > ib/docker/overlay2/38d1544d080145c7d76150530d0255991dfb7258cbca14
> > > ff6d
> > > 165b94353eefab/diff,workdir=/var/lib/docker/overlay2/38d1544d0801
> > > 45c7
> > > d76150530d0255991dfb7258cbca14ff6d165b94353eefab/work)
> > > shm on
> > > /var/lib/docker/containers/662e7f798fc08b09eae0f0f944537a4bcedc1d
> > > cf05
> > > a65866458523ffd4a71614/shm type tmpfs
> > > (rw,nosuid,nodev,noexec,relatime,context="system_u:object_r:svirt
> > > _san
> > > dbox_file_t:s0:c431,c651",size=65536k)
> > > 
> > > sidtab_search_context check the context whether is in the sidtab
> > > list, If not found, a new node is generated and insert into the
> > > list,
> > > As the number of containers is increasing,  context nodes are
> > > also
> > > more and more, we tested the final number of nodes reached
> > > 300,000 +,
> > > sidtab_context_to_sid runtime needs 100-200ms, which will lead to
> > > the
> > > system softlockup.
> > > 
> > > Is this a selinux bug? When filesystem umount, why context node
> > > is
> > > not deleted?  I cannot find the relevant function to delete the
> > > node
> > > in sidtab.c
> > > 
> > > Thanks for reading and looking forward to your reply.
> > 
> > So, does docker just keep allocating a unique category set for
> > every
> > new container, never reusing them even if the container is
> > destroyed? 
> > That would

Re: PAM Security related issue

[Stephen Smalley]

On Tue, 2017-12-12 at 23:47 -0500, Aman Sharma wrote:
> Hi All,
> 
> just wanted to know the meaning of line session    required   
>  pam_selinux.so open env_params added in /etc/pam.d/sshd file.
> Actually I am facing one issue related to this. When I changed this
> env_params to restore then my Sftp is not working. 
> 
> Can anybody Please guide me on this.

man pam_selinux describes the options and what they mean.
Why did you change it to restore?  Per the man page, restore is to
temporarily restore the contexts and would be a separate entry in the
PAM stack before the module that needs the original contexts, followed
by a pam_selinux.so open env_params after that module to set them up
again.  But don't use restore unless you actually need it for some
reason.

Re: [BUG]kernel softlockup due to sidtab_search_context run for long time because of too many sidtab context node

[Stephen Smalley]

On Thu, 2017-12-14 at 09:00 -0800, Casey Schaufler wrote:
> On 12/14/2017 8:42 AM, Stephen Smalley wrote:
> > On Thu, 2017-12-14 at 08:18 -0800, Casey Schaufler wrote:
> > > On 12/13/2017 7:18 AM, Stephen Smalley wrote:
> > > > On Wed, 2017-12-13 at 09:25 +, yangjihong wrote:
> > > > > Hello, 
> > > > > 
> > > > > I am doing stressing testing on 3.10 kernel(centos 7.4), to
> > > > > constantly starting numbers of docker ontainers with selinux
> > > > > enabled,
> > > > > and after about 2 days, the kernel softlockup panic:
> > > > >    [] sched_show_task+0xb8/0x120
> > > > >  [] show_lock_info+0x20f/0x3a0
> > > > >  [] watchdog_timer_fn+0x1da/0x2f0
> > > > >  [] ?
> > > > > watchdog_enable_all_cpus.part.4+0x40/0x40
> > > > >  [] __hrtimer_run_queues+0xd2/0x260
> > > > >  [] hrtimer_interrupt+0xb0/0x1e0
> > > > >  [] local_apic_timer_interrupt+0x37/0x60
> > > > >  [] smp_apic_timer_interrupt+0x50/0x140
> > > > >  [] apic_timer_interrupt+0x6d/0x80
> > > > >    [] ?
> > > > > sidtab_context_to_sid+0xb3/0x480
> > > > >  [] ? sidtab_context_to_sid+0x110/0x480
> > > > >  [] ? mls_setup_user_range+0x145/0x250
> > > > >  [] security_get_user_sids+0x3f7/0x550
> > > > >  [] sel_write_user+0x12b/0x210
> > > > >  [] ? sel_write_member+0x200/0x200
> > > > >  [] selinux_transaction_write+0x48/0x80
> > > > >  [] vfs_write+0xbd/0x1e0
> > > > >  [] SyS_write+0x7f/0xe0
> > > > >  [] system_call_fastpath+0x16/0x1b
> > > > > 
> > > > > My opinion:
> > > > > when the docker container starts, it would mount overlay
> > > > > filesystem
> > > > > with different selinux context, mount point such as: 
> > > > > overlay on
> > > > > /var/lib/docker/overlay2/be3ef517730d92fc4530e0e952eae4f6cb0f
> > > > > 07b4
> > > > > bc32
> > > > > 6cb07495ca08fc9ddb66/merged type overlay
> > > > > (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:
> > > > > s0:c
> > > > > 414,
> > > > > c873",lowerdir=/var/lib/docker/overlay2/l/Z4U7WY6ASNV5CFWLADP
> > > > > ARHH
> > > > > WY7:
> > > > > /var/lib/docker/overlay2/l/V2S3HOKEFEOQLHBVAL5WLA3YLS:/var/li
> > > > > b/do
> > > > > cker
> > > > > /overlay2/l/46YGYO474KLOULZGDSZDW2JPRI,upperdir=/var/lib/dock
> > > > > er/o
> > > > > verl
> > > > > ay2/be3ef517730d92fc4530e0e952eae4f6cb0f07b4bc326cb07495ca08f
> > > > > c9dd
> > > > > b66/
> > > > > diff,workdir=/var/lib/docker/overlay2/be3ef517730d92fc4530e0e
> > > > > 952e
> > > > > ae4f
> > > > > 6cb0f07b4bc326cb07495ca08fc9ddb66/work)
> > > > > shm on
> > > > > /var/lib/docker/containers/9fd65e177d2132011d7b422755793449c9
> > > > > 1327
> > > > > ca57
> > > > > 7b8f5d9d6a4adf218d4876/shm type tmpfs
> > > > > (rw,nosuid,nodev,noexec,relatime,context="system_u:object_r:s
> > > > > virt
> > > > > _san
> > > > > dbox_file_t:s0:c414,c873",size=65536k)
> > > > > overlay on
> > > > > /var/lib/docker/overlay2/38d1544d080145c7d76150530d0255991dfb
> > > > > 7258
> > > > > cbca
> > > > > 14ff6d165b94353eefab/merged type overlay
> > > > > (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:
> > > > > s0:c
> > > > > 431,
> > > > > c651",lowerdir=/var/lib/docker/overlay2/l/3MQQXB4UCLFB7ANVRHP
> > > > > AVRC
> > > > > RSS:
> > > > > /var/lib/docker/overlay2/l/46YGYO474KLOULZGDSZDW2JPRI,upperdi
> > > > > r=/v
> > > > > ar/l
> > > > > ib/docker/overlay2/38d1544d080145c7d76150530d0255991dfb7258cb
> > > > > ca14
> > > > > ff6d
> > > > > 165b94353eefab/diff,workdir=/var/lib/docker/overlay2/38d1544d
> > > > > 0801
> > > > > 45c7
> > > > > d76150530d0255991dfb7258cbca14ff6d165b94353eefab/work)
> > > > > shm on
> > > > > /var/lib/docker/containers/662e7f798fc08b09eae0f0f944537a4bce
> > > &

Re: Object range_transition issue when type_transition is involved

[Stephen Smalley]

On Mon, 2017-12-18 at 17:36 +, Arnold, Paul C CTR USARMY PEO STRI
(US) wrote:
> All,
>  
> I am experiencing some issues using range_transition on objects when
> type_transition is also involved on the object.  Specifically, a
> range_transition rule on a target object with a "final" type (e.g. a
> type which went through a type_transition) does not seem to perform
> the range transition.
>  
>  
> For example, using a private var log type (uses a type_transition
> from var_log_t) does not perform the range transition:
>  
> range_transition mydomain_t mypriv_var_log_t:file mySystemHigh;
>  
>  
> I am confident my source domain is correct, I believe the issue is
> with the target object.  Policy version is 24.

Sorry, are you saying that mydomain_t is creating a file in /var/log,
and that you both want the file type to be set to mypriv_var_log_t and
the level set to mySystemHigh?

If so, then I believe the correct incantation would be:
type_transition mydomain_t var_log_t:file mypriv_var_log_t;
range_transition mydomain_t var_log_t:file mySystemHigh;
(obviously you might instead be using refpolicy macros/interfaces to
achieve the same end)

In both cases, the source type corresponds to the creating process, the
target type corresponds to the parent directory type, and the new type
or level is applied to new files.

Re: [PATCH] python/semanage: make seobject.py backward compatible

[Stephen Smalley]

On Wed, 2017-12-13 at 13:16 +0100, Petr Lautrbach wrote:
> Commit 985753f changed behavior of seobject class constructors. While
> semanage itself was fixed, there are other tools like
> system-config-selinux and chcat which depend on the original
> behavior.
> This change make the constructors backward compatible.
> 
> Fixes: $ system-config-selinux
> Traceback (most recent call last):
>   File "/usr/share/system-config-selinux/system-config-selinux.py",
> line 196, in 
> app = childWindow()
>   File "/usr/share/system-config-selinux/system-config-selinux.py",
> line 100, in __init__
> self.add_page(booleansPage.booleansPage(xml))
>   File "/usr/share/system-config-selinux/booleansPage.py", line 142,
> in __init__
> self.load(self.filter)
>   File "/usr/share/system-config-selinux/booleansPage.py", line 212,
> in load
> self.booleans = seobject.booleanRecords()
> TypeError: __init__() missing 1 required positional argument: 'args'
> 
> Signed-off-by: Petr Lautrbach 

Thanks, applied.

> ---
>  python/semanage/seobject.py | 45 +
> 
>  1 file changed, 25 insertions(+), 20 deletions(-)
> 
> diff --git a/python/semanage/seobject.py
> b/python/semanage/seobject.py
> index 770745e4..b927b184 100644
> --- a/python/semanage/seobject.py
> +++ b/python/semanage/seobject.py
> @@ -240,17 +240,22 @@ class semanageRecords:
>  store = None
>  args = None
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  global handle
> -self.args = args
> -try:
> -self.noreload = args.noreload
> -except:
> -self.noreload = False
> -self.sh = self.get_handle(args.store)
> +if args:
> +# legacy code - args was store originally
> +if type(args) == str:
> +self.store = args
> +else:
> +self.args = args
> +self.noreload = getattr(args, "noreload", False)
> +if not self.store:
> +self.store = getattr(args, "store", "")
> +
> +self.sh = self.get_handle(self.store)
>  
>  rc, localstore = selinux.selinux_getpolicytype()
> -if args.store == "" or args.store == localstore:
> +if self.store == "" or self.store == localstore:
>  self.mylog = logger()
>  else:
>  self.mylog = nulllogger()
> @@ -331,7 +336,7 @@ class semanageRecords:
>  
>  class moduleRecords(semanageRecords):
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  semanageRecords.__init__(self, args)
>  
>  def get_all(self):
> @@ -443,7 +448,7 @@ class moduleRecords(semanageRecords):
>  
>  class dontauditClass(semanageRecords):
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  semanageRecords.__init__(self, args)
>  
>  def toggle(self, dontaudit):
> @@ -456,7 +461,7 @@ class dontauditClass(semanageRecords):
>  
>  class permissiveRecords(semanageRecords):
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  semanageRecords.__init__(self, args)
>  
>  def get_all(self):
> @@ -525,7 +530,7 @@ class permissiveRecords(semanageRecords):
>  
>  class loginRecords(semanageRecords):
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  semanageRecords.__init__(self, args)
>  self.oldsename = None
>  self.oldserange = None
> @@ -782,7 +787,7 @@ class loginRecords(semanageRecords):
>  
>  class seluserRecords(semanageRecords):
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  semanageRecords.__init__(self, args)
>  
>  def get(self, name):
> @@ -1045,7 +1050,7 @@ class portRecords(semanageRecords):
>  except RuntimeError:
>  valid_types = []
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  semanageRecords.__init__(self, args)
>  
>  def __genkey(self, port, proto):
> @@ -1320,7 +1325,7 @@ class ibpkeyRecords(semanageRecords):
>  except:
>  valid_types = []
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  semanageRecords.__init__(self, args)
>  
>  def __genkey(self, pkey, subnet_prefix):
> @@ -1573,7 +1578,7 @@ class ibendportRecords(semanageRecords):
>  except:
>  valid_types = []
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  semanageRecords.__init__(self, args)
>  
>  def __genkey(self, ibendport, ibdev_name):
> @@ -1809,7 +1814,7 @@ class nodeRecords(semanageRecords):
>  except RuntimeError:
>  valid_types = []
>  
> -def __init__(self, args):
> +def __init__(self, args = None):
>  semanageRecords.__init__(self, args)
>  self.protocol = ["ipv4", "ipv6"]
>  
> @@ -2045,7 +2050,7 @@ class nodeRecords(semanageRecords):
>  
>  class 

Re: [BUG]kernel softlockup due to sidtab_search_context run for long time because of too many sidtab context node

[Stephen Smalley]

On Fri, 2017-12-15 at 03:09 +, yangjihong wrote:
> On 12/15/2017 10:31 PM, yangjihong wrote:
> > On 12/14/2017 12:42 PM, Casey Schaufler wrote:
> > > On 12/14/2017 9:15 AM, Stephen Smalley wrote:
> > > > On Thu, 2017-12-14 at 09:00 -0800, Casey Schaufler wrote:
> > > > > On 12/14/2017 8:42 AM, Stephen Smalley wrote:
> > > > > > On Thu, 2017-12-14 at 08:18 -0800, Casey Schaufler wrote:
> > > > > > > On 12/13/2017 7:18 AM, Stephen Smalley wrote:
> > > > > > > > On Wed, 2017-12-13 at 09:25 +, yangjihong wrote:
> > > > > > > > > Hello,
> > > > > > > > > 
> > > > > > > > > I am doing stressing testing on 3.10 kernel(centos
> > > > > > > > > 7.4), to 
> > > > > > > > > constantly starting numbers of docker ontainers with
> > > > > > > > > selinux 
> > > > > > > > > enabled, and after about 2 days, the kernel
> > > > > > > > > softlockup panic:
> > > > > > > > >     []
> > > > > > > > > sched_show_task+0xb8/0x120
> > > > > > > > >   [] show_lock_info+0x20f/0x3a0
> > > > > > > > >   [] watchdog_timer_fn+0x1da/0x2f0
> > > > > > > > >   [] ?
> > > > > > > > > watchdog_enable_all_cpus.part.4+0x40/0x40
> > > > > > > > >   []
> > > > > > > > > __hrtimer_run_queues+0xd2/0x260
> > > > > > > > >   [] hrtimer_interrupt+0xb0/0x1e0
> > > > > > > > >   []
> > > > > > > > > local_apic_timer_interrupt+0x37/0x60
> > > > > > > > >   []
> > > > > > > > > smp_apic_timer_interrupt+0x50/0x140
> > > > > > > > >   [] apic_timer_interrupt+0x6d/0x80
> > > > > > > > >     [] ?
> > > > > > > > > sidtab_context_to_sid+0xb3/0x480
> > > > > > > > >   [] ?
> > > > > > > > > sidtab_context_to_sid+0x110/0x480
> > > > > > > > >   [] ?
> > > > > > > > > mls_setup_user_range+0x145/0x250
> > > > > > > > >   []
> > > > > > > > > security_get_user_sids+0x3f7/0x550
> > > > > > > > >   [] sel_write_user+0x12b/0x210
> > > > > > > > >   [] ? sel_write_member+0x200/0x200
> > > > > > > > >   []
> > > > > > > > > selinux_transaction_write+0x48/0x80
> > > > > > > > >   [] vfs_write+0xbd/0x1e0
> > > > > > > > >   [] SyS_write+0x7f/0xe0
> > > > > > > > >   [] system_call_fastpath+0x16/0x1b
> > > > > > > > > 
> > > > > > > > > My opinion:
> > > > > > > > > when the docker container starts, it would mount
> > > > > > > > > overlay 
> > > > > > > > > filesystem with different selinux context, mount
> > > > > > > > > point such as:
> > > > > > > > > overlay on
> > > > > > > > > /var/lib/docker/overlay2/be3ef517730d92fc4530e0e952ea
> > > > > > > > > e4f6cb0f
> > > > > > > > > 07b4
> > > > > > > > > bc32
> > > > > > > > > 6cb07495ca08fc9ddb66/merged type overlay
> > > > > > > > > (rw,relatime,context="system_u:object_r:svirt_sandbox
> > > > > > > > > _file_t:
> > > > > > > > > s0:c
> > > > > > > > > 414,
> > > > > > > > > c873",lowerdir=/var/lib/docker/overlay2/l/Z4U7WY6ASNV
> > > > > > > > > 5CFWLADP
> > > > > > > > > ARHH
> > > > > > > > > WY7:
> > > > > > > > > /var/lib/docker/overlay2/l/V2S3HOKEFEOQLHBVAL5WLA3YLS
> > > > > > > > > :/var/li
> > > > > > > > > b/do
> > > > > > > > > cker
> > > > > > > > > /overlay2/l/46YGYO474KLOULZGDSZDW2JPRI,upperdir=/var/
> > > > > > > > > lib/dock
> > > > > > > > > er/o
> > > > > 

Re: PAM Security related issue

[Stephen Smalley]

On Wed, 2017-12-13 at 21:40 +0530, Aman Sharma wrote:
> Hi Stephen,
> 
> Yes , I am using open env_params for it. But for this, my sftp is not
> working and getting the below error message :
> 
> Dec 13 13:00:00 aman authpriv 3 sshd: pam_selinux(sshd:session):
> Unable to get valid context for sftpuser
> Dec 13 13:00:00 aman authpriv 6 sshd: pam_unix(sshd:session): session
> opened for user sftpuser by (uid=0)
> 
> Please let me know if you have any idea on this.

Do you have any semanage login mapping for sftpuser or is it just using
the __default__ entry? (what does semanage login -l show)  How was
sftpuser created?

You could add the debug option on the pam_selinux.so line to try to get
more information.

You could run selinuxdefcon to query what context would be used for
that user, e.g.
selinuxdefcon sftpuser system_u:system_r:sshd_t:s0-s0.c0123

> 
> On Wed, Dec 13, 2017 at 8:54 PM, Stephen Smalley <s...@tycho.nsa.gov>
> wrote:
> > On Tue, 2017-12-12 at 23:47 -0500, Aman Sharma wrote:
> > > Hi All,
> > >
> > > just wanted to know the meaning of line session    required   
> > >  pam_selinux.so open env_params added in /etc/pam.d/sshd file.
> > > Actually I am facing one issue related to this. When I changed
> > this
> > > env_params to restore then my Sftp is not working. 
> > >
> > > Can anybody Please guide me on this.
> > 
> > man pam_selinux describes the options and what they mean.
> > Why did you change it to restore?  Per the man page, restore is to
> > temporarily restore the contexts and would be a separate entry in
> > the
> > PAM stack before the module that needs the original contexts,
> > followed
> > by a pam_selinux.so open env_params after that module to set them
> > up
> > again.  But don't use restore unless you actually need it for some
> > reason.
> > 
> > 
> > 
> > 
> 
> 
> 
> -- 
> 
> Thanks
> Aman
> Cell: +91 9990296404 |  Email ID : amansh.shar...@gmail.com

Re: [BUG]kernel softlockup due to sidtab_search_context run for long time because of too many sidtab context node

[Stephen Smalley]

On Wed, 2017-12-13 at 09:25 +, yangjihong wrote:
> Hello, 
> 
> I am doing stressing testing on 3.10 kernel(centos 7.4), to
> constantly starting numbers of docker ontainers with selinux enabled,
> and after about 2 days, the kernel softlockup panic:
>    [] sched_show_task+0xb8/0x120
>  [] show_lock_info+0x20f/0x3a0
>  [] watchdog_timer_fn+0x1da/0x2f0
>  [] ? watchdog_enable_all_cpus.part.4+0x40/0x40
>  [] __hrtimer_run_queues+0xd2/0x260
>  [] hrtimer_interrupt+0xb0/0x1e0
>  [] local_apic_timer_interrupt+0x37/0x60
>  [] smp_apic_timer_interrupt+0x50/0x140
>  [] apic_timer_interrupt+0x6d/0x80
>    [] ? sidtab_context_to_sid+0xb3/0x480
>  [] ? sidtab_context_to_sid+0x110/0x480
>  [] ? mls_setup_user_range+0x145/0x250
>  [] security_get_user_sids+0x3f7/0x550
>  [] sel_write_user+0x12b/0x210
>  [] ? sel_write_member+0x200/0x200
>  [] selinux_transaction_write+0x48/0x80
>  [] vfs_write+0xbd/0x1e0
>  [] SyS_write+0x7f/0xe0
>  [] system_call_fastpath+0x16/0x1b
> 
> My opinion:
> when the docker container starts, it would mount overlay filesystem
> with different selinux context, mount point such as: 
> overlay on
> /var/lib/docker/overlay2/be3ef517730d92fc4530e0e952eae4f6cb0f07b4bc32
> 6cb07495ca08fc9ddb66/merged type overlay
> (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:s0:c414,
> c873",lowerdir=/var/lib/docker/overlay2/l/Z4U7WY6ASNV5CFWLADPARHHWY7:
> /var/lib/docker/overlay2/l/V2S3HOKEFEOQLHBVAL5WLA3YLS:/var/lib/docker
> /overlay2/l/46YGYO474KLOULZGDSZDW2JPRI,upperdir=/var/lib/docker/overl
> ay2/be3ef517730d92fc4530e0e952eae4f6cb0f07b4bc326cb07495ca08fc9ddb66/
> diff,workdir=/var/lib/docker/overlay2/be3ef517730d92fc4530e0e952eae4f
> 6cb0f07b4bc326cb07495ca08fc9ddb66/work)
> shm on
> /var/lib/docker/containers/9fd65e177d2132011d7b422755793449c91327ca57
> 7b8f5d9d6a4adf218d4876/shm type tmpfs
> (rw,nosuid,nodev,noexec,relatime,context="system_u:object_r:svirt_san
> dbox_file_t:s0:c414,c873",size=65536k)
> overlay on
> /var/lib/docker/overlay2/38d1544d080145c7d76150530d0255991dfb7258cbca
> 14ff6d165b94353eefab/merged type overlay
> (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:s0:c431,
> c651",lowerdir=/var/lib/docker/overlay2/l/3MQQXB4UCLFB7ANVRHPAVRCRSS:
> /var/lib/docker/overlay2/l/46YGYO474KLOULZGDSZDW2JPRI,upperdir=/var/l
> ib/docker/overlay2/38d1544d080145c7d76150530d0255991dfb7258cbca14ff6d
> 165b94353eefab/diff,workdir=/var/lib/docker/overlay2/38d1544d080145c7
> d76150530d0255991dfb7258cbca14ff6d165b94353eefab/work)
> shm on
> /var/lib/docker/containers/662e7f798fc08b09eae0f0f944537a4bcedc1dcf05
> a65866458523ffd4a71614/shm type tmpfs
> (rw,nosuid,nodev,noexec,relatime,context="system_u:object_r:svirt_san
> dbox_file_t:s0:c431,c651",size=65536k)
> 
> sidtab_search_context check the context whether is in the sidtab
> list, If not found, a new node is generated and insert into the list,
> As the number of containers is increasing,  context nodes are also
> more and more, we tested the final number of nodes reached 300,000 +,
> sidtab_context_to_sid runtime needs 100-200ms, which will lead to the
> system softlockup.
> 
> Is this a selinux bug? When filesystem umount, why context node is
> not deleted?  I cannot find the relevant function to delete the node
> in sidtab.c
> 
> Thanks for reading and looking forward to your reply.

So, does docker just keep allocating a unique category set for every
new container, never reusing them even if the container is destroyed? 
That would be a bug in docker IMHO.  Or are you creating an unbounded
number of containers and never destroying the older ones?

On the selinux userspace side, we'd also like to eliminate the use of
/sys/fs/selinux/user (sel_write_user -> security_get_user_sids)
entirely, which is what triggered this for you.

We cannot currently delete a sidtab node because we have no way of
knowing if there are any lingering references to the SID.  Fixing that
would require reference-counted SIDs, which goes beyond just SELinux
since SIDs/secids are returned by LSM hooks and cached in other kernel
data structures.

sidtab_search_context() could no doubt be optimized for the negative
case; there was an earlier optimization for the positive case by adding
a cache to sidtab_context_to_sid() prior to calling it.  It's a reverse
lookup in the sidtab.

Re: [RFC v0.1][PATCH] selinuxns: extend namespace support to security.selinux xattrs

[Stephen Smalley]

On Mon, 2017-11-13 at 17:45 +1100, James Morris wrote:
> On Tue, 31 Oct 2017, Stephen Smalley wrote:
> 
> > This btw would be a bit cleaner if we dropped the .ns. portion of
> > the
> > name, such that we would have:
> > security.selinux # xattr name in the init namespace
> > security.selinux.vmN # xattr name in the vmN namespace
> > security.selinux.vmN.vmM # xattr name in the vmN.vmM namespace
> 
> Ok, just to clarify, the namespace name in the last example is
> "vmN.vmM", 
> not "vmM" ?
> 
> i.e. the namespaces are always hierarchical, and the security labels
> are 
> identified by that hierarchy.  If you enter vmM from the init
> namespace, 
> for example, the security labels for it are distinct from the labels
> under 
> vmN.  On disk, you would have both:
> 
> security.selinux.vmM
> security.selinux.vmN.vmM
> 
> which are independent.
> 
> Each of these instances would potentially inherit different labels,
> and 
> have different provenance characteristics, so this seems necessary in
> any 
> case.

Yes, at least with respect to the absolute namespace name maintained
within the kernel and used for xattr names. Not clear what should
happen with respect to the names written to or read from
/sys/fs/selinux/unshare; conceptually it seems cleaner if those are
relative to the namespace of the caller, such that if a process that is
already in "vmN" writes "vmM" to /sys/fs/selinux/unshare, then it ends
up in "vmN.vmM" automatically. But if we applied the same principle to
reading, then a subsequent read from /sys/fs/selinux/unshare would give
back the empty string since the process is already in that namespace. 
Was also wondering if the name read for the init namespace ought to
just be the empty string instead of the magic "init" value to make it
consistent with the fact that there is no xattr suffix.

Then there is the question of what to do upon a collision, e.g. if a
second process in "vmN" writes "vmM" to /sys/fs/selinux/unshare. We
could either fail with EEXIST and require the caller to use a unique
name relative to its current namespace or use this as a way to enter an
already existing namespace ala setns(2) for other namespaces, i.e. look
up the namespace named "vmN.vmM" and switch to it.

Re: [RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache

[Stephen Smalley]

On Wed, 2017-11-01 at 00:08 +0100, Florian Westphal wrote:
> Paul Moore <p...@paul-moore.com> wrote:
> > On Mon, Oct 30, 2017 at 10:58 AM, Stephen Smalley <s...@tycho.nsa.go
> > v> wrote:
> > > matching before (as in this patch) or after calling
> > > xfrm_bundle_ok()?
> > 
> > I would probably make the LSM call the last check, as you've done;
> > but
> > I have to say that is just so it is consistent with the "LSM last"
> > philosophy and not because of any performance related argument.
> > 
> > > ... Also,
> > > do we need to test xfrm->sel.family before calling
> > > xfrm_selector_match
> > > (as in this patch) or not - xfrm_state_look_at() does so when the
> > > state is XFRM_STATE_VALID but not when it is _ERROR or _EXPIRED?
> > 
> > Speaking purely from a SELinux perspective, I'm not sure it
> > matters:
> > as long as the labels match we are happy.  However, from a general
> > IPsec perspective it does seem like a reasonable thing.
> > 
> > Granted I'm probably missing something, but it seems a little odd
> > that
> > the code isn't already checking that the selectors match (... what
> > am
> > I missing?).  It does check the policies, maybe that is enough in
> > the
> > normal IPsec case?
> 
> The assumption was that identical policies would yield the same SAs,
> but thats not correct.
> 
> > > diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> > > index 2746b62..171818b 100644
> > > --- a/net/xfrm/xfrm_policy.c
> > > +++ b/net/xfrm/xfrm_policy.c
> > > @@ -1820,6 +1820,11 @@ xfrm_resolve_and_create_bundle(struct
> > > xfrm_policy **pols, int num_pols,
> > > !xfrm_pol_dead(xdst) &&
> > > memcmp(xdst->pols, pols,
> > >    sizeof(struct xfrm_policy *) * num_pols) == 0
> > > &&
> > > +   (!xdst->u.dst.xfrm->sel.family ||
> > > +xfrm_selector_match(>u.dst.xfrm->sel, fl,
> > > +xdst->u.dst.xfrm->sel.family))
> > > &&
> > > +   security_xfrm_state_pol_flow_match(xdst->u.dst.xfrm,
> > > +          xdst->pols[0], fl)
> > > &&
> 
> ... so this needs to walk the bundle and validate each selector.
> 
> Alternatively we could always do template resolution and then check
> that all states found match those of the old pcpu xdst:

With your patch below, the selinux-testsuite passes, and I couldn't
trigger any failures even running the inet_socket tests repeatedly.

Tested-by: Stephen Smalley <s...@tycho.nsa.gov>

> 
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -1786,19 +1786,23 @@ void xfrm_policy_cache_flush(void)
>   put_online_cpus();
>  }
>  
> -static bool xfrm_pol_dead(struct xfrm_dst *xdst)
> +static bool xfrm_xdst_can_reuse(struct xfrm_dst *xdst,
> + struct xfrm_state * const xfrm[],
> + int num)
>  {
> - unsigned int num_pols = xdst->num_pols;
> - unsigned int pol_dead = 0, i;
> + const struct dst_entry *dst = >u.dst;
> + int i;
>  
> - for (i = 0; i < num_pols; i++)
> - pol_dead |= xdst->pols[i]->walk.dead;
> + if (xdst->num_xfrms != num)
> + return false;
>  
> - /* Mark DST_OBSOLETE_DEAD to fail the next xfrm_dst_check()
> */
> - if (pol_dead)
> - xdst->u.dst.obsolete = DST_OBSOLETE_DEAD;
> + for (i = 0; i < num; i++) {
> + if (!dst || dst->xfrm != xfrm[i])
> + return false;
> + dst = dst->child;
> + }
>  
> - return pol_dead;
> + return xfrm_bundle_ok(xdst);
>  }
>  
>  static struct xfrm_dst *
> @@ -1812,26 +1816,28 @@ xfrm_resolve_and_create_bundle(struct
> xfrm_policy **pols, int num_pols,
>   struct dst_entry *dst;
>   int err;
>  
> + /* Try to instantiate a bundle */
> + err = xfrm_tmpl_resolve(pols, num_pols, fl, xfrm, family);
> + if (err <= 0) {
> + if (err != 0 && err != -EAGAIN)
> + XFRM_INC_STATS(net,
> LINUX_MIB_XFRMOUTPOLERROR);
> + return ERR_PTR(err);
> + }
> +
>   xdst = this_cpu_read(xfrm_last_dst);
>   if (xdst &&
>   xdst->u.dst.dev == dst_orig->dev &&
>   xdst->num_pols == num_pols &&a

Re: [RFC v0.1][PATCH] selinuxns: extend namespace support to security.selinux xattrs

[Stephen Smalley]

On Wed, 2017-11-01 at 17:40 +1100, James Morris wrote:
> On Tue, 31 Oct 2017, Stephen Smalley wrote:
> 
> > This btw would be a bit cleaner if we dropped the .ns. portion of
> > the
> > name, such that we would have:
> > security.selinux # xattr name in the init namespace
> > security.selinux.vmN # xattr name in the vmN namespace
> > security.selinux.vmN.vmM # xattr name in the vmN.vmM namespace
> 
> I used 'ns' to diffetentiate against other potential extensions of
> the 
> xattr name.  If that's not a concern, then yes it will be cleaner.
> 
> Do we limit the number of nestings?

Not in the current code, but I think we will need to do so. That's
mentioned in the list of known issues in the next-to-last commit:

* There is no way currently to restrict or bound nesting of
namespaces; if you allow it to a domain in the init namespace,
then that domain can in turn unshare to arbitrary depths and can
grant the same to any domain in its own policy.  Related to this
is the fact that there is no way to control resource usage due to
selinux namespaces and they can be substantial (per-namespace
policydb, sidtab, AVC, etc).

Re: [RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache

[Stephen Smalley]

On Wed, 2017-11-01 at 17:39 -0400, Paul Moore wrote:
> On Tue, Oct 31, 2017 at 7:08 PM, Florian Westphal <f...@strlen.de>
> wrote:
> > Paul Moore <p...@paul-moore.com> wrote:
> > > On Mon, Oct 30, 2017 at 10:58 AM, Stephen Smalley <s...@tycho.nsa.
> > > gov> wrote:
> > > > matching before (as in this patch) or after calling
> > > > xfrm_bundle_ok()?
> > > 
> > > I would probably make the LSM call the last check, as you've
> > > done; but
> > > I have to say that is just so it is consistent with the "LSM
> > > last"
> > > philosophy and not because of any performance related argument.
> > > 
> > > > ... Also,
> > > > do we need to test xfrm->sel.family before calling
> > > > xfrm_selector_match
> > > > (as in this patch) or not - xfrm_state_look_at() does so when
> > > > the
> > > > state is XFRM_STATE_VALID but not when it is _ERROR or
> > > > _EXPIRED?
> > > 
> > > Speaking purely from a SELinux perspective, I'm not sure it
> > > matters:
> > > as long as the labels match we are happy.  However, from a
> > > general
> > > IPsec perspective it does seem like a reasonable thing.
> > > 
> > > Granted I'm probably missing something, but it seems a little odd
> > > that
> > > the code isn't already checking that the selectors match (...
> > > what am
> > > I missing?).  It does check the policies, maybe that is enough in
> > > the
> > > normal IPsec case?
> > 
> > The assumption was that identical policies would yield the same
> > SAs,
> > but thats not correct.
> 
> Well, to be fair, I think the assumption is valid for normal,
> unlabeled IPsec.  The problem comes when SELinux starts labeling SAs
> and now you have multiple SAs for a given policy, each differing only
> in the SELinux/LSM label.

No, it is invalid for normal, unlabeled IPSEC too, in the case where
one has defined xfrm state selectors.  That's what my other testsuite
patch (which is presently only on the xfrmselectortest branch) is
exercising - matching of xfrm state selectors.  But in any event,
Florian's patch fixes both, so I'm fine with it.  I don't know though
how it compares performance-wise with walking the bundle and just
calling security_xfrm_state_pol_flow_match() and xfrm_selector_match()
on each one.

> 
> Considering that adding the SELinux/LSM label effectively adds an
> additional selector, I'm wondering if we should simply add the
> SELinux/LSM label matching to xfrm_selector_match()?  Looking quickly
> at the code it seems as though we always follow xfrm_selector_match()
> with a LSM check anyway, the one exception being in
> __xfrm_policy_check() ... which *might* be a valid exception, as we
> don't do our access checks for inbound traffic at that point in the
> stack.

Possibly, but that should probably be a separate patch. We should just
fix this regression for 4.14, either via Florian's patch or by
augmenting my patch to perform the matching calls on all of the xfrms.

> 
> > > > diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> > > > index 2746b62..171818b 100644
> > > > --- a/net/xfrm/xfrm_policy.c
> > > > +++ b/net/xfrm/xfrm_policy.c
> > > > @@ -1820,6 +1820,11 @@ xfrm_resolve_and_create_bundle(struct
> > > > xfrm_policy **pols, int num_pols,
> > > > !xfrm_pol_dead(xdst) &&
> > > > memcmp(xdst->pols, pols,
> > > >    sizeof(struct xfrm_policy *) * num_pols) ==
> > > > 0 &&
> > > > +   (!xdst->u.dst.xfrm->sel.family ||
> > > > +xfrm_selector_match(>u.dst.xfrm->sel, fl,
> > > > +xdst->u.dst.xfrm->sel.family)) 
> > > > &&
> > > > +   security_xfrm_state_pol_flow_match(xdst-
> > > > >u.dst.xfrm,
> > > > +  xdst->pols[0],
> > > > fl) &&
> > 
> > ... so this needs to walk the bundle and validate each selector.
> > 
> > Alternatively we could always do template resolution and then check
> > that all states found match those of the old pcpu xdst:
> > 
> > diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> > --- a/net/xfrm/xfrm_policy.c
> > +++ b/net/xfrm/xfrm_policy.c
> > @@ -1786,19 +1786,23 @@ void xfrm_policy_cache_flush(void)
> > put_online_cpus();
> >  }
> > 
> 

Re: [PATCH] python/semanage: Do not try to reload policy when SELinux is disabled

[Stephen Smalley]

On Thu, 2017-11-02 at 14:19 +0100, Petr Lautrbach wrote:
> When SELinux is disabled, semanage without -N fails with a quite
> complicated
> error message when it tries to reload a new policy. Since reload in
> this case
> doesn't make sense, we should probably try to avoid that.

I haven't looked closely at this yet, but I know libsemanage itself
internally sets ->do_reload to false if is_selinux_enabled() is 0 (or
-1), so why is it that seobject.py is manually deciding whether to
reload policy?

> 
> Fixes:
> $ sudo umount /sys/fs/selinux
> 
> $ sudo semanage fcontext -a --type=postfix_local_tmp_t
> /var/opt/01789667
> SELinux:  Could not downgrade policy file
> /etc/selinux/targeted/policy/policy.31, searching for an older
> version.
> SELinux:  Could not open policy file <=
> /etc/selinux/targeted/policy/policy.31:  No such file or directory
> /sbin/load_policy:  Can't load policy:  No such file or directory
> libsemanage.semanage_reload_policy: load_policy returned error code
> 2. (No such file or directory).
> SELinux:  Could not downgrade policy file
> /etc/selinux/targeted/policy/policy.31, searching for an older
> version.
> SELinux:  Could not open policy file <=
> /etc/selinux/targeted/policy/policy.31:  No such file or directory
> /sbin/load_policy:  Can't load policy:  No such file or directory
> libsemanage.semanage_reload_policy: load_policy returned error code
> 2. (No such file or directory).
> FileNotFoundError: [Errno 2] No such file or directory
> 
> Signed-off-by: Petr Lautrbach 
> ---
>  python/semanage/seobject.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/python/semanage/seobject.py
> b/python/semanage/seobject.py
> index 1385315f..37f2b8c6 100644
> --- a/python/semanage/seobject.py
> +++ b/python/semanage/seobject.py
> @@ -241,7 +241,7 @@ class semanageRecords:
>  
>  def __init__(self, store):
>  global handle
> -self.load = True
> +self.load = selinux.is_selinux_enabled()
>  self.sh = self.get_handle(store)
>  
>  rc, localstore = selinux.selinux_getpolicytype()
> @@ -251,7 +251,7 @@ class semanageRecords:
>  self.mylog = nulllogger()
>  
>  def set_reload(self, load):
> -self.load = load
> +self.load = selinux.is_selinux_enabled() and load
>  
>  def get_handle(self, store):
>  global is_mls_enabled

Re: [PATCH] python/semanage: Do not try to reload policy when SELinux is disabled

[Stephen Smalley]

On Thu, 2017-11-02 at 15:17 +0100, Petr Lautrbach wrote:
> On Thu, Nov 02, 2017 at 09:52:25AM -0400, Stephen Smalley wrote:
> > On Thu, 2017-11-02 at 14:19 +0100, Petr Lautrbach wrote:
> > > When SELinux is disabled, semanage without -N fails with a quite
> > > complicated
> > > error message when it tries to reload a new policy. Since reload
> > > in
> > > this case
> > > doesn't make sense, we should probably try to avoid that.
> > 
> > I haven't looked closely at this yet, but I know libsemanage itself
> > internally sets ->do_reload to false if is_selinux_enabled() is 0
> > (or
> > -1), so why is it that seobject.py is manually deciding whether to
> > reload policy?
> 
> semanageRecords.commit() method calls semanage_set_reload(self.sh,
> self.load)
> and this overrides the default value set in semanage_handle_create()
> 
> the flow something like this:
> 
> seobject: __init__(self, store):
> self.sh = self.get_handle(store)
> 
> semanage: semanageRecords.get_handle()
> handle = semanage_handle_create()
> 
> libsemanage: semanage_handle_create()
> sh->do_reload = (is_selinux_enabled() > 0);
> 
> seobject: commit()
> semanage_set_reload(self.sh, self.load)
> 
> Looking into this, the check if SELinux is enabled could be moved to
> libsemanage: semanage_set_reload() and maybe with WARN message in
> case
> that it doesn't set a new value.

Hmm...why does seobject.py call semanage_set_reload() at all except in
the case where it is explicitly called with -N and wants to forcibly
suppress policy reload?  If we can avoid making the call except in that
case, then we don't need to change libsemanage at all.

> 
> 
> > > 
> > > Fixes:
> > > $ sudo umount /sys/fs/selinux
> > > 
> > > $ sudo semanage fcontext -a --type=postfix_local_tmp_t
> > > /var/opt/01789667
> > > SELinux:  Could not downgrade policy file
> > > /etc/selinux/targeted/policy/policy.31, searching for an older
> > > version.
> > > SELinux:  Could not open policy file <=
> > > /etc/selinux/targeted/policy/policy.31:  No such file or
> > > directory
> > > /sbin/load_policy:  Can't load policy:  No such file or directory
> > > libsemanage.semanage_reload_policy: load_policy returned error
> > > code
> > > 2. (No such file or directory).
> > > SELinux:  Could not downgrade policy file
> > > /etc/selinux/targeted/policy/policy.31, searching for an older
> > > version.
> > > SELinux:  Could not open policy file <=
> > > /etc/selinux/targeted/policy/policy.31:  No such file or
> > > directory
> > > /sbin/load_policy:  Can't load policy:  No such file or directory
> > > libsemanage.semanage_reload_policy: load_policy returned error
> > > code
> > > 2. (No such file or directory).
> > > FileNotFoundError: [Errno 2] No such file or directory
> > > 
> > > Signed-off-by: Petr Lautrbach <plaut...@redhat.com>
> > > ---
> > >  python/semanage/seobject.py | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/python/semanage/seobject.py
> > > b/python/semanage/seobject.py
> > > index 1385315f..37f2b8c6 100644
> > > --- a/python/semanage/seobject.py
> > > +++ b/python/semanage/seobject.py
> > > @@ -241,7 +241,7 @@ class semanageRecords:
> > >  
> > >  def __init__(self, store):
> > >  global handle
> > > -self.load = True
> > > +self.load = selinux.is_selinux_enabled()
> > >  self.sh = self.get_handle(store)
> > >  
> > >  rc, localstore = selinux.selinux_getpolicytype()
> > > @@ -251,7 +251,7 @@ class semanageRecords:
> > >  self.mylog = nulllogger()
> > >  
> > >  def set_reload(self, load):
> > > -self.load = load
> > > +self.load = selinux.is_selinux_enabled() and load
> > >  
> > >  def get_handle(self, store):
> > >  global is_mls_enabled
> 
> 

Re: security_bounded_transition

[Stephen Smalley]

On Sat, 2017-11-04 at 11:36 +0100, Christian Göttsche via Selinux
wrote:
> Now that nnp transitions are available in kernel v4.14, can the
> selinux_err message be skipped? (maybe conditional if the policy
> capability for nnp transitions is enabled)
> 
> Cause now I am getting these logs:
> 
> time->Sat Nov  4 11:30:21 2017
> type=PROCTITLE msg=audit(1509791421.220:2221):
> proctitle=2F7573722F62696E2F64706B67002D2D7072696E742D666F726569676E2
> D61726368697465637475726573
> type=PATH msg=audit(1509791421.220:2221): item=1
> name="/lib64/ld-linux-x86-64.so.2" inode=131141 dev=08:01
> mode=0100755
> ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
> nametype=NORMAL cap_fp= cap_fi=
>  cap_fe=0 cap_fver=0
> type=PATH msg=audit(1509791421.220:2221): item=0 name="/usr/bin/dpkg"
> inode=394494 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
> obj=system_u:object_r:dpkg_exec_t:s0 nametype=NORMAL
> cap_fp= cap_fi= cap_f
> e=0 cap_fver=0
> type=CWD msg=audit(1509791421.220:2221):
> cwd="/root/workspace/selinux/policy"
> type=EXECVE msg=audit(1509791421.220:2221): argc=2 a0="/usr/bin/dpkg"
> a1="--print-foreign-architectures"
> type=SYSCALL msg=audit(1509791421.220:2221): arch=c03e syscall=59
> success=yes exit=0 a0=564d70b9cea0 a1=564d70b977f0 a2=7fffa1d32450
> a3=2 items=2 ppid=20592 pid=20593 auid=0 uid=109 gid=65534 euid=109
> suid=109 fsuid=109 egid=65534 sg
> id=65534 fsgid=65534 tty=pts1 ses=1 comm="dpkg" exe="/usr/bin/dpkg"
> subj=root:sysadm_r:apt_t:s0-s0:c0.c1023 key=(null)
> type=SELINUX_ERR msg=audit(1509791421.220:2221):
> op=security_bounded_transition seresult=denied
> oldcontext=root:sysadm_r:apt_t:s0-s0:c0.c1023
> newcontext=root:sysadm_r:dpkg_t:s0-s0:c0.c1023
> type=AVC msg=audit(1509791421.220:2221): avc:  denied  {
> nnp_transition } for  pid=20593 comm="apt-config"
> scontext=root:sysadm_r:apt_t:s0-s0:c0.c1023
> tcontext=root:sysadm_r:dpkg_t:s0-s0:c0.c1023 tclass=process2
> permissive=0
> 
> I like to dontaudit the transition (and let apt stay in the apt_t
> domain for these operations) but the selinux_err message will keep
> showing up.

I don't think we want to silence them in general, and we don't have any
equivalent to dontaudit rules for the bounds checks.

I would think that you would actually want to allow the nnp_transition
so that apt could transition into a more specific domain when running
dpkg.  Not doing so means two things:
1) You have to allow apt_t to directly do anything dpkg_t can do,
2) Any files created by dpkg running under apt will be labeled
according to apt_t's type transition rules rather than dpkg_t's type
transition rules.

This may not matter much with your default policy (I don't know) but it
is generally undesirable.

> 
> 2017-04-05 16:57 GMT+02:00 Dominick Grift <dac.overr...@gmail.com>:
> > On Wed, Apr 05, 2017 at 10:54:08AM -0400, Stephen Smalley wrote:
> > > On Wed, 2017-04-05 at 14:58 +0200, cgzones wrote:
> > > > Hi list,
> > > > 
> > > > when running `apt update` i'm getting a bunch of the following
> > > > security_bounded_transition audits:
> > > > 
> > > > type=PROCTITLE msg=audit(05/04/17 14:47:20.268:219) :
> > > > proctitle=/usr/bin/dpkg --print-foreign-architectures
> > > > type=PATH msg=audit(05/04/17 14:47:20.268:219) : item=1
> > > > name=/lib64/ld-linux-x86-64.so.2 inode=132140 dev=08:01
> > > > mode=file,755
> > > > ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0
> > > > nametype=NORMAL
> > > > type=PATH msg=audit(05/04/17 14:47:20.268:219) : item=0
> > > > name=/usr/bin/dpkg inode=131862 dev=08:01 mode=file,755
> > > > ouid=root
> > > > ogid=root rdev=00:00 obj=system_u:object_r:dpkg_exec_t:s0
> > > > nametype=NORMAL
> > > > type=CWD msg=audit(05/04/17 14:47:20.268:219) :
> > > > cwd=/root/selinux/policy
> > > > type=EXECVE msg=audit(05/04/17 14:47:20.268:219) : argc=2
> > > > a0=/usr/bin/dpkg a1=--print-foreign-architectures
> > > > type=SYSCALL msg=audit(05/04/17 14:47:20.268:219) : arch=x86_64
> > > > syscall=execve success=yes exit=0 a0=0x56455b39a820
> > > > a1=0x56455b39e6d0
> > > > a2=0x7ffdfaf43cd0 a3=0x2 items=2 ppid=2328 pid=2329
> > > > auid=debianuser
> > > > uid=_apt gid=nogroup euid=_apt suid
> > > > =_apt fsuid=_apt egid=nogroup sgid=nogroup fsgid=nogroup
> > > > tty=pts0
> > > > ses=1 comm=dpkg exe=/usr/bin/dpkg
> > > > subj=staff

Re: Qwery regarding Selinux Change Id context

[Stephen Smalley]

On Mon, 2017-12-04 at 21:31 +0530, Aman Sharma wrote:
> Hi Stephen,
> 
> I got the below logs from the file .Can you please if these logs are
> fine or not :
> 
> journalctl | grep selinux
> Dec 05 02:55:46 localhost.localdomain kernel: EVM: security.selinux
> Dec 04 21:26:10 cucm audispd[569]: node=localhost.localdomain
> type=USER_START msg=audit(1512402970.129:107): pid=7145 uid=0 auid=0
> ses=2 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
> msg='op=PAM:session_open
> grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyin
> it,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog
> acct="root" exe="/usr/sbin/sshd" hostname=10.97.7.209
> addr=10.97.7.209 terminal=ssh res=success'
> Dec 04 21:26:10 cucm audispd[569]: node=localhost.localdomain
> type=USER_START msg=audit(1512402970.131:108): pid=7568 uid=0 auid=0
> ses=3 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
> msg='op=PAM:session_open
> grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyin
> it,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog
> acct="root" exe="/usr/sbin/sshd" hostname=10.97.7.209
> addr=10.97.7.209 terminal=ssh res=success'
> 
> Please let me know if any comments are there.

Those are normal.  Check journalctl and /var/log/secure for any errors
from sshd.
Also try the selinuxdefcon command I mentioned.

> 
> On Mon, Dec 4, 2017 at 9:10 PM, Stephen Smalley <s...@tycho.nsa.gov>
> wrote:
> > On Sat, 2017-12-02 at 09:29 +0530, Aman Sharma wrote:
> > > Hi All,
> > >
> > > Thanks for the information.
> > >
> > > But after resetting the semanage User/login, and moving the
> > targeted
> > > folder to old one and then install the default target. then also
> > its
> > > still showing the 
> > > Id context as context=system_u:system_r:unconfined_t:s0-
> > s0:c0.c1023.
> > >
> > > What I observed is after changing the permission using semanage
> > > command also, its still showing the system_u:system_r. 
> > >
> > > Check the semanage login/User output :
> > >
> > > semanage login -l
> > >
> > > Login Name           SELinux User         MLS/MCS Range       
> > > Service
> > >
> > > __default__          unconfined_u         s0-s0:c0.c1023       *
> > > root                 unconfined_u         s0-s0:c0.c1023       *
> > > system_u             system_u             s0-s0:c0.c1023       *
> > >
> > >
> > > semanage user -l
> > >
> > >                 Labeling   MLS/       MLS/                       
> >   
> > > SELinux User    Prefix     MCS Level  MCS Range                 
> >    
> > > SELinux Roles
> > >
> > > guest_u         user       s0         s0                         
> >  
> > >  guest_r
> > > root            user       s0         s0-s0:c0.c1023             
> >  
> > >  staff_r sysadm_r system_r unconfined_r
> > > staff_u         user       s0         s0-s0:c0.c1023             
> >  
> > >  staff_r sysadm_r system_r unconfined_r
> > > sysadm_u        user       s0         s0-s0:c0.c1023             
> >  
> > >  sysadm_r
> > > system_u        user       s0         s0-s0:c0.c1023             
> >  
> > >  system_r unconfined_r
> > > unconfined_u    user       s0         s0-s0:c0.c1023             
> >  
> > >  system_r unconfined_r
> > > user_u          user       s0         s0                         
> >  
> > >  user_r
> > > xguest_u        user       s0         s0                         
> >  
> > >  xguest_r
> > >
> > >
> > > Looks like its related to some other issue. What you think about
> > > this.
> > 
> > Do you have any relevant error messages in /var/log/secure or
> > journalctl -rb?  Look for anything that refers to selinux or
> > context.
> > 
> > I'm guessing that pam_selinux is unable to determine a valid
> > context
> > for your login for some reason, and this is causing it to fall back
> > to
> > this one.  Or something like that.
> > 
> > You could try to emulate this process via selinuxdefcon, although
> > I'm
> > not sure how closely it matches pam_selinux anymore.  Sample usage:
> > 
> > 1. See what context sshd is running in.
> > 
> > ps -eZ | grep sshd
> > 
> > It should be:
> > system_u:system_r:sshd_t:s0-s0:c0.c1023
> > 
> > 2. Run selinuxdefcon to compute the default context for root when
> > logging in from sshd:
> > 
> > # Second argument should be whatever was shown by ps -eZ | grep
> > sshd
> > above.
> > selinuxdefcon root system_u:system_r:sshd_t:s0-s0.c0123
> > 
> > It should be:
> > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > 
> > 
> > 
> 
> 
> 
> -- 
> 
> Thanks
> Aman
> Cell: +91 9990296404 |  Email ID : amansh.shar...@gmail.com

Re: KASAN: slab-out-of-bounds Read in strcmp

[Stephen Smalley]

On Sun, 2017-12-03 at 20:33 +0900, Tetsuo Handa wrote:
> On 2017/12/02 3:52, syzbot wrote:
> > ==
> > BUG: KASAN: slab-out-of-bounds in strcmp+0x96/0xb0 lib/string.c:328
> > Read of size 1 at addr 8801cd99d2c1 by task
> > syzkaller242593/3087
> > 
> > CPU: 0 PID: 3087 Comm: syzkaller242593 Not tainted 4.15.0-rc1-next-
> > 20171201+ #57
> > Hardware name: Google Google Compute Engine/Google Compute Engine,
> > BIOS Google 01/01/2011
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:17 [inline]
> >  dump_stack+0x194/0x257 lib/dump_stack.c:53
> >  print_address_description+0x73/0x250 mm/kasan/report.c:252
> >  kasan_report_error mm/kasan/report.c:351 [inline]
> >  kasan_report+0x25b/0x340 mm/kasan/report.c:409
> >  __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
> >  strcmp+0x96/0xb0 lib/string.c:328
> 
> This seems to be out of bound read for "scontext" at
> 
>   for (i = 1; i < SECINITSID_NUM; i++) {
>   if (!strcmp(initial_sid_to_string[i], scontext)) {
>   *sid = i;
>   return 0;
>   }
>   }
> 
> because "initial_sid_to_string[i]" is "const char *".
> 
> >  security_context_to_sid_core+0x437/0x620
> > security/selinux/ss/services.c:1420
> >  security_context_to_sid+0x32/0x40
> > security/selinux/ss/services.c:1479
> >  selinux_setprocattr+0x51c/0xb50 security/selinux/hooks.c:5986
> >  security_setprocattr+0x85/0xc0 security/security.c:1264
> 
> If "value" does not terminate with '\0' or '\n', "value" and
> "size" are as-is passed to "scontext" and "scontext_len" above
> 
>   /* Obtain a SID for the context, if one was specified. */
>   if (size && str[0] && str[0] != '\n') {
>   if (str[size-1] == '\n') {
>   str[size-1] = 0;
>   size--;
>   }
>   error = security_context_to_sid(value, size, ,
> GFP_KERNEL);
> 
> which will allow strcmp() to trigger out of bound read when "size" is
> larger than strlen(initial_sid_to_string[i]).
> 
> Thus, I guess the simplest fix is to use strncmp() instead of
> strcmp().

Already fixed by
https://www.spinics.net/lists/selinux/msg23589.html

> 
> >  proc_pid_attr_write+0x1e6/0x280 fs/proc/base.c:2574
> >  __vfs_write+0xef/0x970 fs/read_write.c:480
> >  __kernel_write+0xfe/0x350 fs/read_write.c:501
> >  write_pipe_buf+0x175/0x220 fs/splice.c:797
> >  splice_from_pipe_feed fs/splice.c:502 [inline]
> >  __splice_from_pipe+0x328/0x730 fs/splice.c:626
> >  splice_from_pipe+0x1e9/0x330 fs/splice.c:661
> >  default_file_splice_write+0x40/0x90 fs/splice.c:809
> >  do_splice_from fs/splice.c:851 [inline]
> >  direct_splice_actor+0x125/0x180 fs/splice.c:1018
> >  splice_direct_to_actor+0x2c1/0x820 fs/splice.c:973
> >  do_splice_direct+0x2a7/0x3d0 fs/splice.c:1061
> >  do_sendfile+0x5d5/0xe90 fs/read_write.c:1413
> >  SYSC_sendfile64 fs/read_write.c:1468 [inline]
> >  SyS_sendfile64+0xbd/0x160 fs/read_write.c:1460
> >  entry_SYSCALL_64_fastpath+0x1f/0x96

Re: Qwery regarding Selinux Change Id context

[Stephen Smalley]

On Sat, 2017-12-02 at 09:29 +0530, Aman Sharma wrote:
> Hi All,
> 
> Thanks for the information.
> 
> But after resetting the semanage User/login, and moving the targeted
> folder to old one and then install the default target. then also its
> still showing the 
> Id context as context=system_u:system_r:unconfined_t:s0-s0:c0.c1023.
> 
> What I observed is after changing the permission using semanage
> command also, its still showing the system_u:system_r. 
> 
> Check the semanage login/User output :
> 
> semanage login -l
> 
> Login Name           SELinux User         MLS/MCS Range       
> Service
> 
> __default__          unconfined_u         s0-s0:c0.c1023       *
> root                 unconfined_u         s0-s0:c0.c1023       *
> system_u             system_u             s0-s0:c0.c1023       *
> 
> 
> semanage user -l
> 
>                 Labeling   MLS/       MLS/                          
> SELinux User    Prefix     MCS Level  MCS Range                     
> SELinux Roles
> 
> guest_u         user       s0         s0                           
>  guest_r
> root            user       s0         s0-s0:c0.c1023               
>  staff_r sysadm_r system_r unconfined_r
> staff_u         user       s0         s0-s0:c0.c1023               
>  staff_r sysadm_r system_r unconfined_r
> sysadm_u        user       s0         s0-s0:c0.c1023               
>  sysadm_r
> system_u        user       s0         s0-s0:c0.c1023               
>  system_r unconfined_r
> unconfined_u    user       s0         s0-s0:c0.c1023               
>  system_r unconfined_r
> user_u          user       s0         s0                           
>  user_r
> xguest_u        user       s0         s0                           
>  xguest_r
> 
> 
> Looks like its related to some other issue. What you think about
> this.

Do you have any relevant error messages in /var/log/secure or
journalctl -rb?  Look for anything that refers to selinux or context.

I'm guessing that pam_selinux is unable to determine a valid context
for your login for some reason, and this is causing it to fall back to
this one.  Or something like that.

You could try to emulate this process via selinuxdefcon, although I'm
not sure how closely it matches pam_selinux anymore.  Sample usage:

1. See what context sshd is running in.

ps -eZ | grep sshd

It should be:
system_u:system_r:sshd_t:s0-s0:c0.c1023

2. Run selinuxdefcon to compute the default context for root when
logging in from sshd:

# Second argument should be whatever was shown by ps -eZ | grep sshd
above.
selinuxdefcon root system_u:system_r:sshd_t:s0-s0.c0123

It should be:
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Re: Qwery regarding Selinux Change Id context

[Stephen Smalley]

On Mon, 2017-12-04 at 22:04 +0530, Aman Sharma wrote:
> Hi Stephen,
> 
> Thanks alot for the help. 
> 
> I got the issue. Its due to the problem in /etc/pam.d/sshd file.
> 
> After fixing this, now is working fine. Thanks alot once again.

Ok, can you explain what exactly what wrong in your /etc/pam.d/sshd
file, so that if someone else encounters this behavior in the future,
they can find a solution in the list archives?

> 
> On Mon, Dec 4, 2017 at 9:39 PM, Stephen Smalley <s...@tycho.nsa.gov>
> wrote:
> > On Mon, 2017-12-04 at 21:31 +0530, Aman Sharma wrote:
> > > Hi Stephen,
> > >
> > > I got the below logs from the file .Can you please if these logs
> > are
> > > fine or not :
> > >
> > > journalctl | grep selinux
> > > Dec 05 02:55:46 localhost.localdomain kernel: EVM:
> > security.selinux
> > > Dec 04 21:26:10 cucm audispd[569]: node=localhost.localdomain
> > > type=USER_START msg=audit(1512402970.129:107): pid=7145 uid=0
> > auid=0
> > > ses=2 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
> > > msg='op=PAM:session_open
> > >
> > grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_key
> > in
> > > it,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog
> > > acct="root" exe="/usr/sbin/sshd" hostname=10.97.7.209
> > > addr=10.97.7.209 terminal=ssh res=success'
> > > Dec 04 21:26:10 cucm audispd[569]: node=localhost.localdomain
> > > type=USER_START msg=audit(1512402970.131:108): pid=7568 uid=0
> > auid=0
> > > ses=3 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
> > > msg='op=PAM:session_open
> > >
> > grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_key
> > in
> > > it,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog
> > > acct="root" exe="/usr/sbin/sshd" hostname=10.97.7.209
> > > addr=10.97.7.209 terminal=ssh res=success'
> > >
> > > Please let me know if any comments are there.
> > 
> > Those are normal.  Check journalctl and /var/log/secure for any
> > errors
> > from sshd.
> > Also try the selinuxdefcon command I mentioned.
> > 
> > >
> > > On Mon, Dec 4, 2017 at 9:10 PM, Stephen Smalley <s...@tycho.nsa.go
> > v>
> > > wrote:
> > > > On Sat, 2017-12-02 at 09:29 +0530, Aman Sharma wrote:
> > > > > Hi All,
> > > > >
> > > > > Thanks for the information.
> > > > >
> > > > > But after resetting the semanage User/login, and moving the
> > > > targeted
> > > > > folder to old one and then install the default target. then
> > also
> > > > its
> > > > > still showing the 
> > > > > Id context as context=system_u:system_r:unconfined_t:s0-
> > > > s0:c0.c1023.
> > > > >
> > > > > What I observed is after changing the permission using
> > semanage
> > > > > command also, its still showing the system_u:system_r. 
> > > > >
> > > > > Check the semanage login/User output :
> > > > >
> > > > > semanage login -l
> > > > >
> > > > > Login Name           SELinux User         MLS/MCS Range     
> >  
> > > > > Service
> > > > >
> > > > > __default__          unconfined_u         s0-s0:c0.c1023     
> >  *
> > > > > root                 unconfined_u         s0-s0:c0.c1023     
> >  *
> > > > > system_u             system_u             s0-s0:c0.c1023     
> >  *
> > > > >
> > > > >
> > > > > semanage user -l
> > > > >
> > > > >                 Labeling   MLS/       MLS/                   
> >    
> > > >   
> > > > > SELinux User    Prefix     MCS Level  MCS Range             
> >    
> > > >    
> > > > > SELinux Roles
> > > > >
> > > > > guest_u         user       s0         s0                     
> >    
> > > >  
> > > > >  guest_r
> > > > > root            user       s0         s0-s0:c0.c1023         
> >    
> > > >  
> > > > >  staff_r sysadm_r system_r unconfined_r
> > > > > staff_u         user       s0         s0-s0:c0.c1023         
> >    
> > > >  
> > > > >  staff_r sysadm_r system_r unconfined_r
> > > > > sysadm_u

Re: Issue regarding Selinux

[Stephen Smalley]

On Mon, 2017-12-04 at 21:45 +0530, Aman Sharma wrote:
> Hi Stephen,
> 
> sestatus -v
> SELinux status:                 enabled
> SELinuxfs mount:                /sys/fs/selinux
> SELinux root directory:         /etc/selinux
> Loaded policy name:             targeted
> Current mode:                   enforcing
> Mode from config file:          enforcing
> Policy MLS status:              enabled
> Policy deny_unknown status:     allowed
> Max kernel policy version:      28
> 
> Process contexts:
> Current context:                system_u:system_r:unconfined_t:s0-
> s0:c0.c1023
> Init context:                   system_u:system_r:init_t:s0
> /usr/sbin/sshd                  system_u:system_r:sshd_t:s0-
> s0:c0.c1023
> 
> File contexts:
> Controlling terminal:           system_u:object_r:sshd_devpts_t:s0
> /etc/passwd                     system_u:object_r:passwd_file_t:s0
> /etc/shadow                     system_u:object_r:shadow_t:s0
> /bin/bash                       system_u:object_r:shell_exec_t:s0
> /bin/login                      system_u:object_r:login_exec_t:s0
> /bin/sh                         system_u:object_r:bin_t:s0 ->
> system_u:object_r:shell_exec_t:s0
> /sbin/agetty                    system_u:object_r:getty_exec_t:s0
> /sbin/init                      system_u:object_r:bin_t:s0 ->
> system_u:object_r:init_exec_t:s0
> /usr/sbin/sshd                  system_u:object_r:sshd_exec_t:s0
> /lib/libc.so.6                  system_u:object_r:lib_t:s0 ->
> system_u:object_r:lib_t:s0
> /lib/ld-linux.so.2              system_u:object_r:lib_t:s0 ->
> system_u:object_r:ld_so_t:s0
> 
> 
>  rpm -q libselinux
> libselinux-2.5-6.el7.i686
> libselinux-2.5-6.el7.x86_64
> 
> Please let me know if you want any other details .

Ok, so this is the same system that has the wrong ssh login context
(per your Current context" and "Controlling terminal" lines above. So
likely the same root cause as that problem.  Look for sshd errors in
/var/log/secure or journalctl, run selinuxdefaultcon as I described to
see whether you can reproduce the incorrect context computation.

[PATCH] selinux-testsuite: inet_socket: test xfrm state selectors

[Stephen Smalley]

Augment the inet_socket ipsec-load configuration and test script
to test xfrm state selectors.  This isn't really testing SELinux
functionality per se but is rather illustrating the lack of xfrm
selector matching in the xdst pcpu cache.

I don't know if we truly want this in the selinux-testsuite; I used
it to confirm that we are not getting proper xfrm state selector
matching with the current xdst pcpu cache code and to test a possible fix.

Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov>
---
 tests/inet_socket/ipsec-load |  7 +--
 tests/inet_socket/test   | 23 ++-
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/tests/inet_socket/ipsec-load b/tests/inet_socket/ipsec-load
index 21e2dfe..ca377b5 100755
--- a/tests/inet_socket/ipsec-load
+++ b/tests/inet_socket/ipsec-load
@@ -5,8 +5,11 @@ ip xfrm policy flush
 ip xfrm state flush
 goodclientcon=`secon -u --pid $$`:`secon -r --pid 
$$`:test_inet_client_t:`secon -m --pid $$`
 badclientcon=`secon -u --pid $$`:`secon -r --pid 
$$`:test_inet_bad_client_t:`secon -m --pid $$`
-ip xfrm state add src 127.0.0.1 dst 127.0.0.1 proto ah spi 0x200 ctx 
$goodclientcon auth sha1 0123456789012345
-ip xfrm state add src 127.0.0.1 dst 127.0.0.1 proto ah spi 0x250 ctx 
$badclientcon auth sha1 0123456789012345
+ip xfrm state add src 127.0.0.1 dst 127.0.0.1 proto ah spi 0x200 ctx 
$goodclientcon auth sha1 0123456789012345 sel proto tcp dport 65535
+ip xfrm state add src 127.0.0.1 dst 127.0.0.1 proto ah spi 0x400 ctx 
$goodclientcon auth sha1 0123456789012345 sel proto tcp dport 65534
+ip xfrm state add src 127.0.0.1 dst 127.0.0.1 proto ah spi 0x250 ctx 
$badclientcon auth sha1 0123456789012345 sel proto tcp dport 65535
+ip xfrm state add src 127.0.0.1 dst 127.0.0.1 proto ah spi 0x300 ctx 
$goodclientcon auth sha1 0123456789012345 sel proto udp dport 65535
+ip xfrm state add src 127.0.0.1 dst 127.0.0.1 proto ah spi 0x350 ctx 
$badclientcon auth sha1 0123456789012345 sel proto udp dport 65535
 ip xfrm policy add src 127.0.0.1 dst 127.0.0.1 proto tcp dir out ctx 
"system_u:object_r:test_spd_t:s0" tmpl proto ah mode transport level required
 ip xfrm policy add src 127.0.0.1 dst 127.0.0.1 proto udp dir out ctx 
"system_u:object_r:test_spd_t:s0" tmpl proto ah mode transport level required
 
diff --git a/tests/inet_socket/test b/tests/inet_socket/test
index 0bda2a4..88a3696 100755
--- a/tests/inet_socket/test
+++ b/tests/inet_socket/test
@@ -7,7 +7,7 @@ BEGIN {
 plan skip_all => "ctx not supported in ip xfrm policy";
 }
 else {
-plan tests => 33;
+plan tests => 36;
 }
 }
 
@@ -159,6 +159,10 @@ if ( ( $pid = fork() ) == 0 ) {
 exec "runcon -t test_inet_server_t $basedir/server stream 65535";
 }
 
+if ( ( $pid2 = fork() ) == 0 ) {
+exec "runcon -t test_inet_server_t $basedir/server stream 65534";
+}
+
 sleep 1;# Give it a moment to initialize.
 
 # Verify that authorized client can communicate with the server.
@@ -166,6 +170,22 @@ $result =
   system "runcon -t test_inet_client_t $basedir/client stream 127.0.0.1 65535";
 ok( $result eq 0 );
 
+# Verify that authorized client can communicate with the server.
+$result =
+  system "runcon -t test_inet_client_t $basedir/client stream 127.0.0.1 65534";
+ok( $result eq 0 );
+
+# Verify that authorized client can communicate with the server.
+$result =
+  system "runcon -t test_inet_client_t $basedir/client stream 127.0.0.1 65535";
+ok( $result eq 0 );
+
+# Verify that authorized client can communicate with the server.
+$result =
+  system "runcon -t test_inet_client_t $basedir/client stream 127.0.0.1 65534";
+ok( $result eq 0 );
+
+
 # Verify that unauthorized client cannot communicate with the server.
 $result = system
 "runcon -t test_inet_bad_client_t -- $basedir/client stream 127.0.0.1 65535 
2>&1";
@@ -183,6 +203,7 @@ ok( $result >> 8 eq 5 );
 
 # Kill the server.
 kill TERM, $pid;
+kill TERM, $pid2;
 
 # Start the dgram server.
 if ( ( $pid = fork() ) == 0 ) {
-- 
2.9.5

[RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache

[Stephen Smalley]

Since 4.14-rc1, the selinux-testsuite has been encountering sporadic
failures during testing of labeled IPSEC. git bisect pointed to
commit ec30d78c14a813db39a647b6a348b4286 ("xfrm: add xdst pcpu cache").
The xdst pcpu cache is only checking that the policies are the same,
but does not validate that the policy, state, and flow match with respect
to security context labeling.  As a result, the wrong SA could be used
and the receiver could end up performing permission checking and
providing SO_PEERSEC or SCM_SECURITY values for the wrong security context.
security_xfrm_state_pol_flow_match() exists for this purpose and is
already called from xfrm_state_look_at() for matching purposes.
Further, xfrm_state_look_at() also performs a xfrm_selector_match() test,
which is also missing from the xdst pcpu cache logic.  Add calls to both
of these functions when validating the cache entry.  With these changes,
the selinux-testsuite passes all tests again.

Fixes: ec30d78c14a813db39a647b6a348b4286ba4abf5 ("xfrm: add xdst pcpu cache")
Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov>
---
This is an RFC because I am not entirely confident in the fix, e.g. is it
sufficient to perform this matching only on the first xfrm or do they all
need to be walked as in xfrm_bundle_ok()?  Also, should we perform this
matching before (as in this patch) or after calling xfrm_bundle_ok()? Also,
do we need to test xfrm->sel.family before calling xfrm_selector_match
(as in this patch) or not - xfrm_state_look_at() does so when the
state is XFRM_STATE_VALID but not when it is _ERROR or _EXPIRED?

 net/xfrm/xfrm_policy.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 2746b62..171818b 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1820,6 +1820,11 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy 
**pols, int num_pols,
!xfrm_pol_dead(xdst) &&
memcmp(xdst->pols, pols,
   sizeof(struct xfrm_policy *) * num_pols) == 0 &&
+   (!xdst->u.dst.xfrm->sel.family ||
+xfrm_selector_match(>u.dst.xfrm->sel, fl,
+xdst->u.dst.xfrm->sel.family)) &&
+   security_xfrm_state_pol_flow_match(xdst->u.dst.xfrm,
+  xdst->pols[0], fl) &&
xfrm_bundle_ok(xdst)) {
dst_hold(>u.dst);
return xdst;
-- 
2.9.5

Re: travis CI

[Stephen Smalley]

On Tue, 2017-10-24 at 23:00 +0200, Nicolas Iooss wrote:
> On Tue, Oct 24, 2017 at 10:20 PM, William Roberts
> <bill.c.robe...@gmail.com> wrote:
> > On Oct 24, 2017 13:05, "Stephen Smalley" <s...@tycho.nsa.gov> wrote:
> > 
> > On Tue, 2017-10-24 at 09:26 -0700, William Roberts wrote:
> > > Error 52, which if it lines up with what I am reading is
> > > CURLE_GOT_NOTHING
> > > https://curl.haxx.se/libcurl/c/libcurl-errors.html
> > > 
> > > That url/command combo seems valid, likely a transient issue with
> > > github.
> > 
> > I restarted the job, and it failed again in the same way (but on
> > different cases).  Then I restarted it a third time, and this time
> > it
> > ran to completion.  This seems problematic; we likely need to
> > reconsider any use of curl from the travis.yml file.
> > 
> > 
> > Weird. I wget things from sourceforge all the time. The only time I
> > have
> > issues is when sourceforge is down.
> > 
> > > On Tue, Oct 24, 2017 at 9:05 AM, Stephen Smalley <s...@tycho.nsa.g
> > > ov>
> > > wrote:
> 
> [[...]]
> > > > Our .travis.yml seems to yield unstable results,
> > > > https://travis-ci.org/SELinuxProject/selinux/jobs/292128434
> > > > 
> > > > Don't know if it would help to instead download a refpolicy
> > > > release
> > > > and
> > > > extract it, or if this is just transient.
> > > > 
> 
> It looks like transient networking issues between Travis-CI and
> Github. A possible fix would consists in using the Ubuntu package
> which provides refpolicy files: selinux-policy-dev. This however
> introduces the drawback that the package pulls in Ubuntu's version of
> checkpolicy, policycoreutils, libsepol... which may introduce
> incorrect test success if they happen to be used instead of the
> programs from the tested build. So I am not convinced by this.
> 
> I am wondering whether using curl's --retry option would help to work
> around the networking issues which occurred. I am testing this in my
> "curl-retry" branch on Github [1] and will submit a patch if you
> think
> this may work.

Sounds reasonable to me as a quick fix.  Another alternative would be
to include a copy of these files in the selinux repo itself to remove
external dependencies, although that doesn't help with python.

A separate issue with the current travis-ci testing is that it doesn't
exercise any of the python component tests.  On the one hand, it could
be argued that is a bug in the python/Makefile in not propagating down
make test to the sudirs, but only some of those tests can be run as
non-root.  One of the audit2allow tests presently is invoked via sudo
(probably could be changed though to pass -o to sepolgen-ifgen to avoid
requiring root), and the semanage tests operate on the system policy
store and thus require root (possibly could be redirected to an
alternate root, but doesn't look like semanage provides such an option,
unlike semodule -p).  We have this strange inconsistency with the
current tests where some of them can only be run as non-root and others
can only be run as root; likely should be fixed in the tests
themselves.

> 
> Nicolas
> 
> [1] https://github.com/fishilico/selinux/commits/curl-retry
> 

Re: travis CI

[Stephen Smalley]

On Wed, 2017-10-18 at 19:30 -0700, William Roberts wrote:
> On Tue, Oct 17, 2017 at 12:50 PM, Stephen Smalley <s...@tycho.nsa.gov>
> wrote:
> > On Tue, 2017-10-17 at 11:49 -0700, William Roberts wrote:
> > > On Sun, Oct 15, 2017 at 5:10 AM, Nicolas Iooss <nicolas.iooss@m4x
> > > .org
> > > > wrote:
> > > > On Fri, Oct 13, 2017 at 1:50 AM, William Roberts
> > > > <bill.c.robe...@gmail.com> wrote:
> > > > > On Thu, Oct 12, 2017 at 1:48 PM, Stephen Smalley <sds@tycho.n
> > > > > sa.g
> > > > > ov> wrote:
> > > > > > On Thu, 2017-10-12 at 11:29 -0700, William Roberts wrote:
> > > > > > > I see a travis.yml file, recently modified by Nicolas,
> > > > > > > but I
> > > > > > > failed
> > > > > > > to
> > > > > > > find the Travis CI instance on travis.org, where is it?
> > > > > > > 
> > > > > > > We should likely have it running on commits to the repo
> > > > > > > and
> > > > > > > PRs so we
> > > > > > > can have some independent way of verifying that our run
> > > > > > > of
> > > > > > > the tests
> > > > > > > was compromised by some env variation or mistake.
> > > > > > > 
> > > > > > > Thoughts?
> > > > > > 
> > > > > > To date he has just run it on his own fork.  Not opposed to
> > > > > > enabling
> > > > > > it, just haven't looked into that...
> > > > > 
> > > > > I have done it for my some of my projects, Ill go ahead and
> > > > > set
> > > > > this up.
> > > > 
> > > > I configured Travis-CI to test the branches in my Github
> > > > repository
> > > > a
> > > > little more than one year ago, after several build
> > > > configurations
> > > > got
> > > > broken (clang on Linux for example). I later added more
> > > > features to
> > > > it
> > > > (for example warning about missing .gitignore entries, testing
> > > > several
> > > > Ruby and Python versions, etc), before I upstreamed my
> > > > .travis.yml
> > > > file (a few months ago). When I did it, my main motivation was
> > > > to
> > > > simplify the job of anyone who would want to configure a CI
> > > > system
> > > > on
> > > > the project (the building rules and dependencies should be
> > > > quite
> > > > similar). Using a continuous integration system is useful to
> > > > prevent
> > > > simple regression issues which would otherwise only be detected
> > > > when
> > > > someone running a specific configuration tries to build the
> > > > project.
> > > > 
> > > > Before asking to enable Travis-CI on the main SELinux
> > > > repository, I
> > > > wanted to make sure it was stable/reliable enough. To do this,
> > > > I
> > > > created a branch named "travis-upstream" in my repository,
> > > > which
> > > > tracked the master branch of the main repository. All went well
> > > > for
> > > > quite some time, until Travis-CI modified this summer their
> > > > environments, introducing some incompatibilities with projects
> > > > which
> > > > use several programming languages. Thankfully these changes
> > > > have
> > > > been
> > > > documented in Travis-CI's blog and I updated the config file to
> > > > fix
> > > > the builds with commits b1ea8120832d ("Travis-CI: use sugulite
> > > > environment") and 6d9258e5a05f ("Travis-CI: fix configuration
> > > > after
> > > > September's update"). As Travis-CI does not seem to want to
> > > > support
> > > > multi-language projects (cf.
> > > > https://github.com/travis-ci/travis-ci/issues/4090 for
> > > > example),
> > > > more
> > > > breaking changes could be introduced as the provided
> > > > environment
> > > > are
> > > > upgraded. Nevertheless I expect that such changes are quite
> > > > easily
> > > > fixable.
> > > > 
> > > > In short, using a CI platfo

Re: travis CI

[Stephen Smalley]

On Tue, 2017-10-24 at 09:26 -0700, William Roberts wrote:
> Error 52, which if it lines up with what I am reading is
> CURLE_GOT_NOTHING
> https://curl.haxx.se/libcurl/c/libcurl-errors.html
> 
> That url/command combo seems valid, likely a transient issue with
> github.

I restarted the job, and it failed again in the same way (but on
different cases).  Then I restarted it a third time, and this time it
ran to completion.  This seems problematic; we likely need to
reconsider any use of curl from the travis.yml file.

> 
> 
> 
> 
> On Tue, Oct 24, 2017 at 9:05 AM, Stephen Smalley <s...@tycho.nsa.gov>
> wrote:
> > On Wed, 2017-10-18 at 19:30 -0700, William Roberts wrote:
> > > On Tue, Oct 17, 2017 at 12:50 PM, Stephen Smalley <s...@tycho.nsa.
> > > gov>
> > > wrote:
> > > > On Tue, 2017-10-17 at 11:49 -0700, William Roberts wrote:
> > > > > On Sun, Oct 15, 2017 at 5:10 AM, Nicolas Iooss  > > > > @m4x
> > > > > .org
> > > > > > wrote:
> > > > > > On Fri, Oct 13, 2017 at 1:50 AM, William Roberts
> > > > > > <bill.c.robe...@gmail.com> wrote:
> > > > > > > On Thu, Oct 12, 2017 at 1:48 PM, Stephen Smalley <sds@tyc
> > > > > > > ho.n
> > > > > > > sa.g
> > > > > > > ov> wrote:
> > > > > > > > On Thu, 2017-10-12 at 11:29 -0700, William Roberts
> > > > > > > > wrote:
> > > > > > > > > I see a travis.yml file, recently modified by
> > > > > > > > > Nicolas,
> > > > > > > > > but I
> > > > > > > > > failed
> > > > > > > > > to
> > > > > > > > > find the Travis CI instance on travis.org, where is
> > > > > > > > > it?
> > > > > > > > > 
> > > > > > > > > We should likely have it running on commits to the
> > > > > > > > > repo
> > > > > > > > > and
> > > > > > > > > PRs so we
> > > > > > > > > can have some independent way of verifying that our
> > > > > > > > > run
> > > > > > > > > of
> > > > > > > > > the tests
> > > > > > > > > was compromised by some env variation or mistake.
> > > > > > > > > 
> > > > > > > > > Thoughts?
> > > > > > > > 
> > > > > > > > To date he has just run it on his own fork.  Not
> > > > > > > > opposed to
> > > > > > > > enabling
> > > > > > > > it, just haven't looked into that...
> > > > > > > 
> > > > > > > I have done it for my some of my projects, Ill go ahead
> > > > > > > and
> > > > > > > set
> > > > > > > this up.
> > > > > > 
> > > > > > I configured Travis-CI to test the branches in my Github
> > > > > > repository
> > > > > > a
> > > > > > little more than one year ago, after several build
> > > > > > configurations
> > > > > > got
> > > > > > broken (clang on Linux for example). I later added more
> > > > > > features to
> > > > > > it
> > > > > > (for example warning about missing .gitignore entries,
> > > > > > testing
> > > > > > several
> > > > > > Ruby and Python versions, etc), before I upstreamed my
> > > > > > .travis.yml
> > > > > > file (a few months ago). When I did it, my main motivation
> > > > > > was
> > > > > > to
> > > > > > simplify the job of anyone who would want to configure a CI
> > > > > > system
> > > > > > on
> > > > > > the project (the building rules and dependencies should be
> > > > > > quite
> > > > > > similar). Using a continuous integration system is useful
> > > > > > to
> > > > > > prevent
> > > > > > simple regression issues which would otherwise only be
> > > > > > detected
> > > > > > when
> > > > > > someone running a specific configuration tries to build

Re: [RFC v0.1][PATCH] selinuxns: extend namespace support to security.selinux xattrs

[Stephen Smalley]

On Tue, 2017-10-31 at 14:11 +1100, James Morris wrote:
> On Mon, 30 Oct 2017, Stephen Smalley wrote:
> 
> > Thanks, interesting approach. One drawback is that it doesn't
> > presently
> > support any form of inheritance of labels from the parent
> > namespace, so
> > files that are shared read-only from the init namespace will show
> > up as
> > unlabeled in the child namespace until they are assigned the
> > namespaced
> > attributes.  This for example breaks running the selinux-testsuite
> > with
> > this patch applied (unless perhaps you run restorecon -R / after
> > unsharing); otherwise just trying to invoke /usr/bin/runcon will
> > fail
> > since it is unlabeled in the child.  It seems like we should
> > provide
> > some form of inheritance from the parent when there is no xattr for
> > the
> > namespace itself.
> 
> I was assuming that practical use of this would involve doing a
> filesystem 
> relabel under the newly loaded policy, on first instantiation at
> least.

I think that would be problematic, e.g. if you want to share /usr read-
only to all of the containers or similar, then they cannot relabel it
themselves and even if you provided a way to set the xattrs from the
init namespace, in the case where you are using the same or very
similar policies, it seems wasteful to set the same xattr values for N
xattr names for N containers.  So I think inheritance support will be
necessary.  This will be easier if we make the xattr names themselves
hierarchical (e.g. if vm8 writes vm1 to /sys/fs/selinux/unshare, then
the child xattr name would be security.selinux.ns.vm8.vm1, and we would
inherit from either security.selinux.ns.vm8 or security.selinux if
security.selinux.ns.vm8.vm1 is not set.)

> 
> We could try adding an selinuxfs node to specify default handling of 
> unlabeled files in a child namespace, and write to that after
> mounting 
> selinuxfs in that namespace.
> 
> e.g. echo inherit > /sys/fs/selinux/parent_ns_labels
> 
> or something.
> 
> 
> > 
> > Another potential concern is that files created in a non-init
> > namespace
> > are left completely unlabeled in the init namespace (or in any
> > parent).
> > As long as access to unlabeled is tightly controlled, this
> > might
> > not be a problem, but I'm not sure that's guaranteed by the
> > refpolicy
> > or Fedora/RHEL policies.  We might want to initialize an xattr at
> > every
> > level of the namespace hierarchy when a new file is created based
> > on
> > the process and parent directory labels and policy at that level. 
> > Otherwise, we lose all provenance information for the file outside
> > of
> > the namespace. 
> 
> Ok.
> 
> 
> > For example, suppose I want to leak information out of
> > my category set; I unshare and create files with the information,
> > and
> > they appear in the init namespace with no categories.
> 
> Nice :)
> 

Re: [RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache

[Stephen Smalley]

On Tue, 2017-10-31 at 12:11 +0100, Florian Westphal wrote:
> Stephen Smalley <s...@tycho.nsa.gov> wrote:
> > Since 4.14-rc1, the selinux-testsuite has been encountering
> > sporadic
> > failures during testing of labeled IPSEC. git bisect pointed to
> > commit ec30d78c14a813db39a647b6a348b4286 ("xfrm: add xdst pcpu
> > cache").
> > The xdst pcpu cache is only checking that the policies are the
> > same,
> > but does not validate that the policy, state, and flow match with
> > respect
> > to security context labeling.  As a result, the wrong SA could be
> > used
> > and the receiver could end up performing permission checking and
> > providing SO_PEERSEC or SCM_SECURITY values for the wrong security
> > context.
> > security_xfrm_state_pol_flow_match() exists for this purpose and is
> > already called from xfrm_state_look_at() for matching purposes.
> > Further, xfrm_state_look_at() also performs a xfrm_selector_match()
> > test,
> > which is also missing from the xdst pcpu cache logic.  Add calls to
> > both
> > of these functions when validating the cache entry.  With these
> > changes,
> > the selinux-testsuite passes all tests again.
> > 
> > Fixes: ec30d78c14a813db39a647b6a348b4286ba4abf5 ("xfrm: add xdst
> > pcpu cache")
> > Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov>
> > ---
> > This is an RFC because I am not entirely confident in the fix, e.g.
> > is it
> > sufficient to perform this matching only on the first xfrm or do
> > they all
> > need to be walked as in xfrm_bundle_ok()?  Also, should we perform
> > this
> > matching before (as in this patch) or after calling
> > xfrm_bundle_ok()? Also,
> > do we need to test xfrm->sel.family before calling
> > xfrm_selector_match
> > (as in this patch) or not - xfrm_state_look_at() does so when the
> > state is XFRM_STATE_VALID but not when it is _ERROR or _EXPIRED?
> 
> No idea.
> 
> I looked at the old flow cache but i don't see any of these extra
> checks there either.
> 
> However, old flow cache stored flowi struct as key, and that contains
> a
> flowi_secid,  populated by the decode_session hooks.
> 
> Was it enough to check for identical flowi_secid in the flowi structs
> to
> avoid this problem or am i missing something?

I'm not sure, but security_xfrm_state_pol_flow_match() ->
selinux_xfrm_state_pol_flow_match() does more than just compare flow
secids.

Also, there is the separate issue of the missing xfrm_selector_match()
call, which can also cause the wrong SA to be used independent of
anything LSM/SELinux-related.

It is a regression; the correct SA was being used prior to the xdst
pcpu cache commit.  Reproducible using the selinux-testsuite, most
easily run on a Fedora VM,
git clone https://github.com/SELinuxProject/selinux-testsuite/
sudo dnf install perl-Test perl-Test-Harness perl-Test-Simple 
selinux-policy-devel gcc libselinux-devel net-tools netlabel_tools iptables
sudo make -C policy load
cd tests/inet_socket
while sudo ./test; do : ; done

Re: [RFC v0.1][PATCH] selinuxns: extend namespace support to security.selinux xattrs

[Stephen Smalley]

On Tue, 2017-10-31 at 09:00 -0400, Stephen Smalley wrote:
> On Tue, 2017-10-31 at 14:11 +1100, James Morris wrote:
> > On Mon, 30 Oct 2017, Stephen Smalley wrote:
> > 
> > > Thanks, interesting approach. One drawback is that it doesn't
> > > presently
> > > support any form of inheritance of labels from the parent
> > > namespace, so
> > > files that are shared read-only from the init namespace will show
> > > up as
> > > unlabeled in the child namespace until they are assigned the
> > > namespaced
> > > attributes.  This for example breaks running the selinux-
> > > testsuite
> > > with
> > > this patch applied (unless perhaps you run restorecon -R / after
> > > unsharing); otherwise just trying to invoke /usr/bin/runcon will
> > > fail
> > > since it is unlabeled in the child.  It seems like we should
> > > provide
> > > some form of inheritance from the parent when there is no xattr
> > > for
> > > the
> > > namespace itself.
> > 
> > I was assuming that practical use of this would involve doing a
> > filesystem 
> > relabel under the newly loaded policy, on first instantiation at
> > least.
> 
> I think that would be problematic, e.g. if you want to share /usr
> read-
> only to all of the containers or similar, then they cannot relabel it
> themselves and even if you provided a way to set the xattrs from the
> init namespace, in the case where you are using the same or very
> similar policies, it seems wasteful to set the same xattr values for
> N
> xattr names for N containers.  So I think inheritance support will be
> necessary.  This will be easier if we make the xattr names themselves
> hierarchical (e.g. if vm8 writes vm1 to /sys/fs/selinux/unshare, then
> the child xattr name would be security.selinux.ns.vm8.vm1, and we
> would
> inherit from either security.selinux.ns.vm8 or security.selinux if
> security.selinux.ns.vm8.vm1 is not set.)

This btw would be a bit cleaner if we dropped the .ns. portion of the
name, such that we would have:
security.selinux # xattr name in the init namespace
security.selinux.vmN # xattr name in the vmN namespace
security.selinux.vmN.vmM # xattr name in the vmN.vmM namespace
...

> 
> > 
> > We could try adding an selinuxfs node to specify default handling
> > of 
> > unlabeled files in a child namespace, and write to that after
> > mounting 
> > selinuxfs in that namespace.
> > 
> > e.g. echo inherit > /sys/fs/selinux/parent_ns_labels
> > 
> > or something.
> > 
> > 
> > > 
> > > Another potential concern is that files created in a non-init
> > > namespace
> > > are left completely unlabeled in the init namespace (or in any
> > > parent).
> > > As long as access to unlabeled is tightly controlled, this
> > > might
> > > not be a problem, but I'm not sure that's guaranteed by the
> > > refpolicy
> > > or Fedora/RHEL policies.  We might want to initialize an xattr at
> > > every
> > > level of the namespace hierarchy when a new file is created based
> > > on
> > > the process and parent directory labels and policy at that
> > > level. 
> > > Otherwise, we lose all provenance information for the file
> > > outside
> > > of
> > > the namespace. 
> > 
> > Ok.
> > 
> > 
> > > For example, suppose I want to leak information out of
> > > my category set; I unshare and create files with the information,
> > > and
> > > they appear in the init namespace with no categories.
> > 
> > Nice :)
> > 

Re: [RFC PATCH] xfrm: fix regression introduced by xdst pcpu cache

[Stephen Smalley]

On Tue, 2017-10-31 at 09:43 -0400, Stephen Smalley wrote:
> On Tue, 2017-10-31 at 12:11 +0100, Florian Westphal wrote:
> > Stephen Smalley <s...@tycho.nsa.gov> wrote:
> > > Since 4.14-rc1, the selinux-testsuite has been encountering
> > > sporadic
> > > failures during testing of labeled IPSEC. git bisect pointed to
> > > commit ec30d78c14a813db39a647b6a348b4286 ("xfrm: add xdst pcpu
> > > cache").
> > > The xdst pcpu cache is only checking that the policies are the
> > > same,
> > > but does not validate that the policy, state, and flow match with
> > > respect
> > > to security context labeling.  As a result, the wrong SA could be
> > > used
> > > and the receiver could end up performing permission checking and
> > > providing SO_PEERSEC or SCM_SECURITY values for the wrong
> > > security
> > > context.
> > > security_xfrm_state_pol_flow_match() exists for this purpose and
> > > is
> > > already called from xfrm_state_look_at() for matching purposes.
> > > Further, xfrm_state_look_at() also performs a
> > > xfrm_selector_match()
> > > test,
> > > which is also missing from the xdst pcpu cache logic.  Add calls
> > > to
> > > both
> > > of these functions when validating the cache entry.  With these
> > > changes,
> > > the selinux-testsuite passes all tests again.
> > > 
> > > Fixes: ec30d78c14a813db39a647b6a348b4286ba4abf5 ("xfrm: add xdst
> > > pcpu cache")
> > > Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov>
> > > ---
> > > This is an RFC because I am not entirely confident in the fix,
> > > e.g.
> > > is it
> > > sufficient to perform this matching only on the first xfrm or do
> > > they all
> > > need to be walked as in xfrm_bundle_ok()?  Also, should we
> > > perform
> > > this
> > > matching before (as in this patch) or after calling
> > > xfrm_bundle_ok()? Also,
> > > do we need to test xfrm->sel.family before calling
> > > xfrm_selector_match
> > > (as in this patch) or not - xfrm_state_look_at() does so when the
> > > state is XFRM_STATE_VALID but not when it is _ERROR or _EXPIRED?
> > 
> > No idea.
> > 
> > I looked at the old flow cache but i don't see any of these extra
> > checks there either.
> > 
> > However, old flow cache stored flowi struct as key, and that
> > contains
> > a
> > flowi_secid,  populated by the decode_session hooks.
> > 
> > Was it enough to check for identical flowi_secid in the flowi
> > structs
> > to
> > avoid this problem or am i missing something?
> 
> I'm not sure, but security_xfrm_state_pol_flow_match() ->
> selinux_xfrm_state_pol_flow_match() does more than just compare flow
> secids.
> 
> Also, there is the separate issue of the missing
> xfrm_selector_match()
> call, which can also cause the wrong SA to be used independent of
> anything LSM/SELinux-related.
> 
> It is a regression; the correct SA was being used prior to the xdst
> pcpu cache commit.  Reproducible using the selinux-testsuite, most
> easily run on a Fedora VM,
> git clone https://github.com/SELinuxProject/selinux-testsuite/
> sudo dnf install perl-Test perl-Test-Harness perl-Test-Simple
> selinux-policy-devel gcc libselinux-devel net-tools netlabel_tools
> iptables

Actually, you should just run 'sudo make test' instead of the
individual commands below.  I was breaking out the individual commands
to avoid running the rest of the testsuite unrelated to networking, but
 that won't pick up all of the dependencies the first time.  Sorry.

> sudo make -C policy load
> cd tests/inet_socket
> while sudo ./test; do : ; done

Re: [PATCH V3 1/2] security: Add a cred_getsecid hook

[Stephen Smalley]

On Mon, 2017-10-30 at 10:57 +, Matthew Garrett via Selinux wrote:
> On Thu, Oct 26, 2017 at 3:20 PM, Stephen Smalley <s...@tycho.nsa.gov>
> wrote:
> > On Thu, 2017-10-26 at 01:40 -0700, Matthew Garrett via Selinux
> > wrote:
> > > +static void selinux_cred_getsecid(const struct cred *c, u32
> > > *secid)
> > > +{
> > > + rcu_read_lock();
> > > + *secid = cred_sid(c);
> > > + rcu_read_unlock();
> > 
> > Is rcu_read_lock() necessary here? Seems like we use cred_sid() in
> > many
> > places without it.
> 
> Ah, I thought it was based on task_sid(), but I guess that's actually
> protecting the __task_cred()?

It appears to me that in all other cases, we are either dealing with
the current cred, or something in the call chain of cred_sid() is
holding a reference to the cred, or something in the call chain of
cred_sid() has called rcu_read_lock() already.  I might have missed
something though, and I don't know how safe it is to assume that all
future callers will do this.  cc'd David for his thoughts.

Re: [RFC v0.1][PATCH] selinuxns: extend namespace support to security.selinux xattrs

[Stephen Smalley]

On Mon, 2017-10-30 at 21:04 +1100, James Morris wrote:
> This is a proof-of-concept patch to demonstrate an approach to
> supporting 
> SELinux namespaces for security.selinux xattr labels.
> 
> This follows on from the experimental SELinux namespace code posted
> by 
> Stephen: https://marc.info/?l=selinux=150696042210126=2
> 
> In the initial code, namespacing was only implemented for in-core
> inodes 
> per this posting: https://marc.info/?l=selinux=150696324110943=2
> 
> In this patch, namespacing is extended to on-disk inode labels
> (xattrs), 
> transparently to normal applications.
> 
> A summary of the approach is as follows:
> 
> 1. Add a namespace "name" field to the SELinux namespace, which is 
>    specified by writing to the selinuxfs unshare node (instead of
> the 
>    current boolean value) during namespace creation.
> 
>    e.g. if the namespace name is "vm8", run: 
> 
>    # echo vm8 > /sys/fs/selinux/unshare
> 
>    followed by the remaining steps from the original code.
> 
>    This value can also be read back from the node, and the initial
> SELinux 
>    namespace is internally set to "init".
> 
>    
> 2. Transparently modify SELinux xattrs so that any non-initial
> namespace 
>    xattrs include the namespace name. 
> 
>    e.g. if the namespace name is "vm6", the "security.selinux" xattr
> is 
>    translated in the kernel to "security.selinux.ns.vm6" for disk
> read and
>    write of xattrs.
> 
>    This allows each SELinux namespace to independently manage its
> own 
>    xattr labels, transparently to applications. Namespaces only see
> their 
>    own xattrs, which are acted on by their own namespaced policies.
> 
>    Note that the "init" namespace performs no translation for apps,
> it 
>    just uses regular old security.selinux xattrs.
> 
> 
> Some examples:
> 
>   [root@test]# cat /sys/fs/selinux/unshare 
>   vm8
> 
>   [root@test]# touch testfile
> 
>   [root@test]# ls -Z testfile 
>   -rw-r--r--. root root unconfined_u:object_r:unlabeled_t:s0 testfile
> 
>   [root@test]# getfattr -n security.selinux testfile 
>   # file: testfile
>   security.selinux="unconfined_u:object_r:unlabeled_t:s0"
> 
>   # restorecon -v testfile 
>   restorecon reset /root/selinux/testfile context
> unconfined_u:object_r:unlabeled_t:s0-
> >unconfined_u:object_r:admin_home_t:s0
> 
>   [root@test]# getfattr -n security.selinux testfile 
>   # file: testfile
>   security.selinux="unconfined_u:object_r:admin_home_t:s0"
> 
>   [root@test]# chcon -t etc_t testfile 
> 
>   [root@test]# getfattr -n security.selinux testfile 
>   # file: testfile
>   security.selinux="unconfined_u:object_r:etc_t:s0"
> 
> 
> Ok, so this all looks pretty normal, but what's happening on disk is
> not.  
> > From the init namespace, I'll access the same file:
> 
>   [root@test]# cat /sys/fs/selinux/unshare 
>   init
> 
>   [root@test]# ls -Z testfile 
>   -rw-r--r--. root root system_u:object_r:unlabeled_t:s0 testfile
> 
>   [root@test]# getfattr -n security.selinux testfile 
>   # file: testfile
>   security.selinux="system_u:object_r:unlabeled_t:s0"
> 
> There is in fact no security.selinux xattr yet on this file as it
> was 
> created in a different namespace and only initialized there.  What
> you're 
> seeing here is the default unlabeled label.  Dumping out the xattrs
> shows 
> what's on disk:
> 
>   [root@test]# getfattr -d -m . testfile 
>   # file: testfile
>   security.selinux.ns.vm8="unconfined_u:object_r:etc_t:s0"
> 
> The xattr belonging to "vm8" is there but not being interpreted
> outside 
> that namespace.  Let's give it a proper label for the init ns:
> 
>   # restorecon -v testfile 
>   restorecon reset /root/selinux/testfile context
> system_u:object_r:unlabeled_t:s0->system_u:object_r:admin_home_t:s0
> 
>   [root@test]# getfattr -d -m . testfile 
>   # file: testfile
>   security.selinux="system_u:object_r:admin_home_t:s0"
>   security.selinux.ns.vm8="unconfined_u:object_r:etc_t:s0"
> 
>   [root@test]# ls -Z testfile 
>   -rw-r--r--. root root system_u:object_r:admin_home_t:s0 testfile
> 
> And if you go into the vm8 namespace you'll see the label there is:
> 
>   [root@test]# echo  vm8 > /sys/fs/selinux/unshare 
>   [root@test]# unshare -m -n
>   [root@test]# umount /sys/fs/selinux && mount -t selinuxfs none
> /sys/fs/selinux && load_policy
>   [root@test]# runcon
> unconfined_u:unconfined_r:unconfined_t:s0:c0.c1023 /bin/bash
>   [root@test]# setenforce 1
> 
>   [root@test]# ls -Z testfile 
>   -rw-r--r--. root root unconfined_u:object_r:etc_t:s0   testfile
> 
> 
> I hope that demonstrates the concept well enough: that there are
> zero 
> changes for applications and the namespaced policy always uses
> xattrs 
> belonging to that namespace.
> 
> The prototype code is far from complete, and also needs to implement 
> support for listxattr and removexattr, as well as provide
> appropriate 
> administrative access to raw (untranslated) xattrs, which you can 
> currently see from any ns but not write at 

Re: [PATCH] python/semanage/seobject.py: Fix undefined store check

[Stephen Smalley]

On 05/04/2018 07:51 AM, Petr Lautrbach wrote:
> From: Vit Mojzis 
> 
> self.store is always a string (actual store name or "") because of
> semanageRecords.__init__. Fix check for not defined store.
> 
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1559174#c3
> 
> Signed-off-by: Vit Mojzis 
> ---
>  python/semanage/seobject.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/python/semanage/seobject.py b/python/semanage/seobject.py
> index ac310ea6..c76dce85 100644
> --- a/python/semanage/seobject.py
> +++ b/python/semanage/seobject.py
> @@ -2651,7 +2651,7 @@ class booleanRecords(semanageRecords):
>  self.current_booleans = []
>  ptype = None
>  
> -if self.store is None or self.store == ptype:
> +if self.store == "" or self.store == ptype:
>  self.modify_local = True
>  else:
>  self.modify_local = False
> 

Is there a reason you didn't use if not self.store here?

Re: [PATCH] python/semanage/seobject.py: Fix undefined store check

[Stephen Smalley]

On 05/04/2018 04:12 PM, Petr Lautrbach wrote:
> On Fri, May 04, 2018 at 01:58:08PM -0400, Stephen Smalley wrote:
>> On 05/04/2018 07:51 AM, Petr Lautrbach wrote:
>>> From: Vit Mojzis <vmoj...@redhat.com>
>>>
>>> self.store is always a string (actual store name or "") because of
>>> semanageRecords.__init__. Fix check for not defined store.
>>>
>>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1559174#c3
>>>
>>> Signed-off-by: Vit Mojzis <vmoj...@redhat.com>
>>> ---
>>>  python/semanage/seobject.py | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/python/semanage/seobject.py b/python/semanage/seobject.py
>>> index ac310ea6..c76dce85 100644
>>> --- a/python/semanage/seobject.py
>>> +++ b/python/semanage/seobject.py
>>> @@ -2651,7 +2651,7 @@ class booleanRecords(semanageRecords):
>>>  self.current_booleans = []
>>>  ptype = None
>>>  
>>> -if self.store is None or self.store == ptype:
>>> +if self.store == "" or self.store == ptype:
>>>  self.modify_local = True
>>>  else:
>>>  self.modify_local = False
>>>
>>
>> Is there a reason you didn't use if not self.store here?
>>
> 
> There's a similar check on line 258 and this just follows the same pattern.

Ok, I don't have a strong opinion on it either way, but noticed that it was 
recommended
to use not self.store in that bugzilla entry, comment #9, and was claimed to 
have been changed
in comment #10.  Up to you.

Re: Packaging policycoreutils for OpenSUSE

[Stephen Smalley]

On 05/13/2018 07:43 AM, Nicolas Iooss wrote:
> On Sat, May 12, 2018 at 2:53 PM, Matěj Cepl  wrote:
>> Hi,
>>
>> I am changing jobs (Red Hat -> SUSE; R, but not a security
>> related job), and although I will be switching my workstation to
>> OpenSUSE, I would love to keep SELinux working. Which meant I had
>> to dig into the current situation of SELinux and it is … not
>> good. So, I started to repackage all SELinux packages 2.7 for
>> OpenSUSE in my home build area
>> https://build.opensuse.org/project/show/home:mcepl:SELinux
>> . So,far I have packaged successfully packages for libselinux,
>> libselinux-bindings, checkpolicy, libsemanage, libsepol, and
>> python-semanage. Mostly I use original OpenSUSE packages for 2.6,
>> but if needed I seek inspiration in Fedora packages.
>>
>> Unfortunately, I have trouble to package policycoreutils. First
>> of all, I don’t understand what’s the difference between two
>> upstream tarballs for it:
>> https://github.com/SELinuxProject/selinux/archive/policycoreutils
>> -2.7.tar.gz
>> (linked from https://github.com/SELinuxProject/selinux/releases)
>> and
>> https://raw.githubusercontent.com/wiki/SELinuxProject/selinux/fil
>> es/releases/20170804/policycoreutils-2.7.tar.gz
>> (linked from
>> https://github.com/SELinuxProject/selinux/wiki/Releases). What’s
>> the point of confusing users with two different tarballs of the
>> same name?
>>
>> Second, I don’t understand the behavior of the installation
>> scripts. Looking at https://is.gd/MivaE1 , why in the world that
>> installation scripts tons of stuff which is not part of
>> policycoreutils? Could anybody help me to get through this
>> obstacle, please?
>>
>> Thank you for any suggestions,
>>
>> Matěj
> 
> Hi,
> After we have discussed about it on IRC (#selinux on freenode), I have
> performed some tests on Github to better understand how its "Releases
> page" work. The main issue here is that Github shows tags of the git
> repository in the Releases page
> (https://github.com/SELinuxProject/selinux/releases) and there is no
> way to disabled this behavior. This has several consequences:
> 
> * Each tarball in https://github.com/SELinuxProject/selinux/releases
> contains the full tree of the project (which is why "that installation
> scripts tons of stuff which is not part of policycoreutils"), whereas
> the tarballs in the wiki page are created by properly splitting the
> subdirectories.
> * It is not possible to delete what is currently in Github's release
> page without deleting the tags.
> * It is possible to "upgrade" a tag to a release by adding release
> notes and files to them. For example
> https://github.com/gentilkiwi/mimikatz/releases uses this (you can see
> the differences between "Releases" and "Tags" pages of this project).
> When there are releases like this, it is possible to remove them all
> (for example using
> https://github.com/stevemao/github-remove-all-releases), which
> transforms the release page back to a list of tags (I have tested this
> today on a test repository).
> 
> Moreover it seems that the Releases page can not be disabled (if it
> can, I have not found how).
> 
> If my analysis of Github's release system is correct, would it make
> sense to change the way the releases are currently tagged to only
> create one tag (like "selinux-2.8-rc3") instead of creating one tag
> per sub-project? Would this break some tools? (If distribution
> packagers use tools to automatically detect when a new release is
> available, would such a change break these tools?)

Not speaking for the distributions obviously, but I have no objection to 
dropping
the per-component tags if they aren't being used and are causing confusion.

A bit of historical context: originally, we released the selinux userspace as a 
single
tarball with a single date-based version.  When SELinux was first being 
integrated into Fedora,
the Fedora packagers wanted releases to be split into separate source tarballs 
for each component each
with its own independent version, so this was done for formal releases but the 
source continued to live
in a single source code repository. (This all predates the move to GitHub, of 
course). 
The individual component versioning has limited utility in my view given that 
there is almost always
at least one source level change to every component between any two releases 
and there tends to be
a strong coupling among many of the components.

In the past, we have considered either going back to a single source tarball 
with a single version,
or splitting the source code repository itself to be per-component.  Either 
approach would allow direct
use of the github releases as the official release mechanism and avoid the need 
to separately create
and maintain the release tarballs on the wiki pages.

Re: [PATCH 20/23] LSM: Move common usercopy into

[Stephen Smalley]

On 05/10/2018 08:55 PM, Casey Schaufler wrote:
> From: Casey Schaufler 
> Date: Thu, 10 May 2018 15:54:25 -0700
> Subject: [PATCH 20/23] LSM: Move common usercopy into
>  security_getpeersec_stream
> 
> The modules implementing hook for getpeersec_stream
> don't need to be duplicating the copy-to-user checks.
> Moving the user copy part into the infrastructure makes
> the security module code simpler and reduces the places
> where user copy code may go awry.
> 
> Signed-off-by: Casey Schaufler 
> ---
>  include/linux/lsm_hooks.h  | 10 --
>  include/linux/security.h   |  6 --
>  security/apparmor/lsm.c| 28 ++--
>  security/security.c| 17 +++--
>  security/selinux/hooks.c   | 22 +++---
>  security/smack/smack_lsm.c | 19 ---
>  6 files changed, 48 insertions(+), 54 deletions(-)
> 
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 81504623afb4..84bc9ec01931 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -841,9 +841,8 @@
>   *   SO_GETPEERSEC.  For tcp sockets this can be meaningful if the
>   *   socket is associated with an ipsec SA.
>   *   @sock is the local socket.
> - *   @optval userspace memory where the security state is to be copied.
> - *   @optlen userspace int where the module should copy the actual length
> - *   of the security state.
> + *   @optval the security state.
> + *   @optlen the actual length of the security state.
>   *   @len as input is the maximum length to copy to userspace provided
>   *   by the caller.
>   *   Return 0 if all is well, otherwise, typical getsockopt return
> @@ -1674,9 +1673,8 @@ union security_list_options {
>   int (*socket_setsockopt)(struct socket *sock, int level, int optname);
>   int (*socket_shutdown)(struct socket *sock, int how);
>   int (*socket_sock_rcv_skb)(struct sock *sk, struct sk_buff *skb);
> - int (*socket_getpeersec_stream)(struct socket *sock,
> - char __user *optval,
> - int __user *optlen, unsigned int len);
> + int (*socket_getpeersec_stream)(struct socket *sock, char **optval,
> + int *optlen, unsigned int len);
>   int (*socket_getpeersec_dgram)(struct socket *sock,
>   struct sk_buff *skb,
>   struct secids *secid);
> diff --git a/include/linux/security.h b/include/linux/security.h
> index ab70064c283f..712d138e0148 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -1369,8 +1369,10 @@ static inline int security_sock_rcv_skb(struct sock 
> *sk,
>   return 0;
>  }
>  
> -static inline int security_socket_getpeersec_stream(struct socket *sock, 
> char __user *optval,
> - int __user *optlen, 
> unsigned len)
> +static inline int security_socket_getpeersec_stream(struct socket *sock,
> + char __user *optval,
> + int __user *optlen,
> + unsigned int len)
>  {
>   return -ENOPROTOOPT;
>  }
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 90453dbb4fac..7444cfa689b3 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1017,10 +1017,8 @@ static struct aa_label *sk_peer_label(struct sock *sk)
>   *
>   * Note: for tcp only valid if using ipsec or cipso on lan
>   */
> -static int apparmor_socket_getpeersec_stream(struct socket *sock,
> -  char __user *optval,
> -  int __user *optlen,
> -  unsigned int len)
> +static int apparmor_socket_getpeersec_stream(struct socket *sock, char 
> **optval,
> +  int *optlen, unsigned int len)
>  {
>   char *name;
>   int slen, error = 0;
> @@ -1037,22 +1035,16 @@ static int apparmor_socket_getpeersec_stream(struct 
> socket *sock,
>FLAG_SHOW_MODE | FLAG_VIEW_SUBNS |
>FLAG_HIDDEN_UNCONFINED, GFP_KERNEL);
>   /* don't include terminating \0 in slen, it breaks some apps */
> - if (slen < 0) {
> + if (slen < 0)
>   error = -ENOMEM;
> - } else {
> - if (slen > len) {
> - error = -ERANGE;
> - } else if (copy_to_user(optval, name, slen)) {
> - error = -EFAULT;
> - goto out;
> - }
> - if (put_user(slen, optlen))
> - error = -EFAULT;
> -out:
> - kfree(name);
> -
> + else if (slen > len)
> + error = -ERANGE;
> + else {
> + *optlen 

Re: [PATCH 20/23] LSM: Move common usercopy into

[Stephen Smalley]

On 05/14/2018 11:12 AM, Stephen Smalley wrote:
> On 05/10/2018 08:55 PM, Casey Schaufler wrote:
>> From: Casey Schaufler <ca...@schaufler-ca.com>
>> Date: Thu, 10 May 2018 15:54:25 -0700
>> Subject: [PATCH 20/23] LSM: Move common usercopy into
>>  security_getpeersec_stream
>>
>> The modules implementing hook for getpeersec_stream
>> don't need to be duplicating the copy-to-user checks.
>> Moving the user copy part into the infrastructure makes
>> the security module code simpler and reduces the places
>> where user copy code may go awry.
>>
>> Signed-off-by: Casey Schaufler <ca...@schaufler-ca.com>
>> ---
>>  include/linux/lsm_hooks.h  | 10 --
>>  include/linux/security.h   |  6 --
>>  security/apparmor/lsm.c| 28 ++--
>>  security/security.c| 17 +++--
>>  security/selinux/hooks.c   | 22 +++---
>>  security/smack/smack_lsm.c | 19 ---
>>  6 files changed, 48 insertions(+), 54 deletions(-)
>>
>> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
>> index 81504623afb4..84bc9ec01931 100644
>> --- a/include/linux/lsm_hooks.h
>> +++ b/include/linux/lsm_hooks.h
>> @@ -841,9 +841,8 @@
>>   *  SO_GETPEERSEC.  For tcp sockets this can be meaningful if the
>>   *  socket is associated with an ipsec SA.
>>   *  @sock is the local socket.
>> - *  @optval userspace memory where the security state is to be copied.
>> - *  @optlen userspace int where the module should copy the actual length
>> - *  of the security state.
>> + *  @optval the security state.
>> + *  @optlen the actual length of the security state.
>>   *  @len as input is the maximum length to copy to userspace provided
>>   *  by the caller.
>>   *  Return 0 if all is well, otherwise, typical getsockopt return
>> @@ -1674,9 +1673,8 @@ union security_list_options {
>>  int (*socket_setsockopt)(struct socket *sock, int level, int optname);
>>  int (*socket_shutdown)(struct socket *sock, int how);
>>  int (*socket_sock_rcv_skb)(struct sock *sk, struct sk_buff *skb);
>> -int (*socket_getpeersec_stream)(struct socket *sock,
>> -char __user *optval,
>> -int __user *optlen, unsigned int len);
>> +int (*socket_getpeersec_stream)(struct socket *sock, char **optval,
>> +int *optlen, unsigned int len);
>>  int (*socket_getpeersec_dgram)(struct socket *sock,
>>  struct sk_buff *skb,
>>  struct secids *secid);
>> diff --git a/include/linux/security.h b/include/linux/security.h
>> index ab70064c283f..712d138e0148 100644
>> --- a/include/linux/security.h
>> +++ b/include/linux/security.h
>> @@ -1369,8 +1369,10 @@ static inline int security_sock_rcv_skb(struct sock 
>> *sk,
>>  return 0;
>>  }
>>  
>> -static inline int security_socket_getpeersec_stream(struct socket *sock, 
>> char __user *optval,
>> -int __user *optlen, 
>> unsigned len)
>> +static inline int security_socket_getpeersec_stream(struct socket *sock,
>> +char __user *optval,
>> +int __user *optlen,
>> +unsigned int len)
>>  {
>>  return -ENOPROTOOPT;
>>  }
>> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
>> index 90453dbb4fac..7444cfa689b3 100644
>> --- a/security/apparmor/lsm.c
>> +++ b/security/apparmor/lsm.c
>> @@ -1017,10 +1017,8 @@ static struct aa_label *sk_peer_label(struct sock *sk)
>>   *
>>   * Note: for tcp only valid if using ipsec or cipso on lan
>>   */
>> -static int apparmor_socket_getpeersec_stream(struct socket *sock,
>> - char __user *optval,
>> - int __user *optlen,
>> - unsigned int len)
>> +static int apparmor_socket_getpeersec_stream(struct socket *sock, char 
>> **optval,
>> + int *optlen, unsigned int len)
>>  {
>>  char *name;
>>  int slen, error = 0;
>> @@ -1037,22 +1035,16 @@ static int apparmor_socket_getpeersec_stream(struct 
>> socket *sock,
>>   FLAG_SHOW_MODE | FLAG_VIEW_SUBNS |
>>  

Re: [PATCH 10/23] LSM: Infrastructure management of the inode security

[Stephen Smalley]

On 05/10/2018 08:53 PM, Casey Schaufler wrote:
> From: Casey Schaufler 
> Date: Thu, 10 May 2018 14:23:27 -0700
> Subject: [PATCH 10/23] LSM: Infrastructure management of the inode security
>  blob
> 
> Move management of the inode->i_security blob out
> of the individual security modules and into the security
> infrastructure. Instead of allocating the blobs from within
> the modules the modules tell the infrastructure how much
> space is required, and the space is allocated there.
> 
> Signed-off-by: Casey Schaufler 
> ---
>  include/linux/lsm_hooks.h |  3 ++
>  security/security.c   | 85 
> +--
>  security/selinux/hooks.c  | 32 +--
>  security/selinux/include/objsec.h |  5 +--
>  security/smack/smack_lsm.c| 70 +---
>  5 files changed, 99 insertions(+), 96 deletions(-)
> 
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 3ba96e406827..a935ab92906d 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -2017,6 +2017,7 @@ struct security_hook_list {
>  struct lsm_blob_sizes {
>   int lbs_cred;
>   int lbs_file;
> + int lbs_inode;
>   int lbs_task;
>  };
>  
> @@ -2080,10 +2081,12 @@ static inline void loadpin_add_hooks(void) { };
>  #endif
>  
>  extern int lsm_cred_alloc(struct cred *cred, gfp_t gfp);
> +extern int lsm_inode_alloc(struct inode *inode);
>  
>  #ifdef CONFIG_SECURITY
>  void lsm_early_cred(struct cred *cred);
>  void lsm_early_task(struct task_struct *task);
> +void lsm_early_inode(struct inode *inode);
>  #endif
>  
>  #endif /* ! __LINUX_LSM_HOOKS_H */
> diff --git a/security/security.c b/security/security.c
> index b414186ad45f..02df9b608b7e 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -41,6 +41,7 @@ struct security_hook_heads security_hook_heads 
> __lsm_ro_after_init;
>  static ATOMIC_NOTIFIER_HEAD(lsm_notifier_chain);
>  
>  static struct kmem_cache *lsm_file_cache;
> +static struct kmem_cache *lsm_inode_cache;
>  
>  char *lsm_names;
>  static struct lsm_blob_sizes blob_sizes;
> @@ -98,6 +99,10 @@ int __init security_init(void)
>   lsm_file_cache = kmem_cache_create("lsm_file_cache",
>  blob_sizes.lbs_file, 0,
>  SLAB_PANIC, NULL);
> + if (blob_sizes.lbs_inode)
> + lsm_inode_cache = kmem_cache_create("lsm_inode_cache",
> + blob_sizes.lbs_inode, 0,
> + SLAB_PANIC, NULL);
>   /*
>* The second call to a module specific init function
>* adds hooks to the hook lists and does any other early
> @@ -108,8 +113,9 @@ int __init security_init(void)
>  #ifdef CONFIG_SECURITY_LSM_DEBUG
>   pr_info("LSM: cred blob size   = %d\n", blob_sizes.lbs_cred);
>   pr_info("LSM: file blob size   = %d\n", blob_sizes.lbs_file);
> + pr_info("LSM: inode blob size  = %d\n", blob_sizes.lbs_inode);
>   pr_info("LSM: task blob size   = %d\n", blob_sizes.lbs_task);
> -#endif
> +#endif /* CONFIG_SECURITY_LSM_DEBUG */
>  
>   return 0;
>  }
> @@ -285,6 +291,13 @@ void __init security_add_blobs(struct lsm_blob_sizes 
> *needed)
>   lsm_set_size(>lbs_cred, _sizes.lbs_cred);
>   lsm_set_size(>lbs_file, _sizes.lbs_file);
>   lsm_set_size(>lbs_task, _sizes.lbs_task);
> + /*
> +  * The inode blob gets an rcu_head in addition to
> +  * what the modules might need.
> +  */
> + if (needed->lbs_inode && blob_sizes.lbs_inode == 0)
> + blob_sizes.lbs_inode = sizeof(struct rcu_head);
> + lsm_set_size(>lbs_inode, _sizes.lbs_inode);
>  }
>  
>  /**
> @@ -348,6 +361,46 @@ void lsm_early_task(struct task_struct *task)
>   panic("%s: Early task alloc failed.\n", __func__);
>  }
>  
> +/**
> + * lsm_inode_alloc - allocate a composite inode blob
> + * @inode: the inode that needs a blob
> + *
> + * Allocate the inode blob for all the modules
> + *
> + * Returns 0, or -ENOMEM if memory can't be allocated.
> + */
> +int lsm_inode_alloc(struct inode *inode)
> +{
> + if (!lsm_inode_cache) {
> + inode->i_security = NULL;
> + return 0;
> + }
> +
> + inode->i_security = kmem_cache_zalloc(lsm_inode_cache, GFP_KERNEL);

Should be GFP_NOFS (and was that way in SELinux and Smack).

> + if (inode->i_security == NULL)
> + return -ENOMEM;
> + return 0;
> +}
> +
> +/**
> + * lsm_early_inode - during initialization allocate a composite inode blob
> + * @inode: the inode that needs a blob
> + *
> + * Allocate the inode blob for all the modules if it's not already there
> + */
> +void lsm_early_inode(struct inode *inode)
> +{
> + int rc;
> +
> + if (inode == NULL)
> + panic("%s: NULL 

Re: Anyone using the SELinux test suite on Fedora 28?

[Stephen Smalley]

It's been running fine for me. Maybe you just need to clean your tree and
do a fresh make test.

On Mon, May 14, 2018, 7:37 PM Casey Schaufler 
wrote:

> Has anyone had success with the SELinux test suite on Fedora 28?
> I find the chcon and newrole are unhappy with the contexts used
> in the suite.
>
>
>

Re: [PATCH] selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()

[Stephen Smalley]

On 05/09/2018 11:01 AM, Paul Moore wrote:
> On Wed, May 9, 2018 at 8:37 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
>> On 05/08/2018 08:25 PM, Paul Moore wrote:
>>> On Tue, May 8, 2018 at 2:40 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
>>>> On 05/08/2018 01:05 PM, Paul Moore wrote:
>>>>> On Tue, May 8, 2018 at 10:05 AM, Alexey Kodanev
>>>>> <alexey.koda...@oracle.com> wrote:
>>>>>> Commit d452930fd3b9 ("selinux: Add SCTP support") breaks compatibility
>>>>>> with the old programs that can pass sockaddr_in with AF_UNSPEC and
>>>>>> INADDR_ANY to bind(). As a result, bind() returns EAFNOSUPPORT error.
>>>>>> It was found with LTP/asapi_01 test.
>>>>>>
>>>>>> Similar to commit 29c486df6a20 ("net: ipv4: relax AF_INET check in
>>>>>> bind()"), which relaxed AF_INET check for compatibility, add AF_UNSPEC
>>>>>> case to AF_INET and make sure that the address is INADDR_ANY.
>>>>>>
>>>>>> Also, in the end of selinux_socket_bind(), instead of adding AF_UNSPEC
>>>>>> to 'address->sa_family == AF_INET', verify AF_INET6 first.
>>>>>>
>>>>>> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
>>>>>> Signed-off-by: Alexey Kodanev <alexey.koda...@oracle.com>
>>>>>> ---
>>>>>>  security/selinux/hooks.c | 12 +---
>>>>>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>>>>
>>>>> Thanks for finding and reporting this regression.
>>>>>
>>>>> I think I would prefer to avoid having to duplicate the
>>>>> AF_UNSPEC/INADDR_ANY checking logic in the SELinux hook, even though
>>>>> it is a small bit of code and unlikely to change.  I'm wondering if it
>>>>> would be better to check both the socket and sockaddr address family
>>>>> in the main if conditional inside selinux_socket_bind(), what do you
>>>>> think?  Another option would be to go back to just checking the
>>>>> soackaddr address family; we moved away from that for a reason which
>>>>> escapes at the moment (code cleanliness?), but perhaps that was a
>>>>> mistake.
>>>>
>>>> We've always used the sk->sk_family there; it was only the recent code 
>>>> from Richard that started
>>>> using the socket address family.
>>>
>>> Yes I know, I thought I was the one that suggested it at some point
>>> (I'll take the blame) ... although now that I'm looking at the git
>>> log, maybe I'm confusing it with something else.
>>>
>>>>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>>>>> index 4cafe6a19167..a3789b167667 100644
>>>>> --- a/security/selinux/hooks.c
>>>>> +++ b/security/selinux/hooks.c
>>>>> @@ -4577,6 +4577,7 @@ static int selinux_socket_bind(struct socket *sock, 
>>>>> struc>
>>>>> {
>>>>>struct sock *sk = sock->sk;
>>>>>u16 family;
>>>>> +   u16 family_sa;
>>>>>int err;
>>>>>
>>>>>err = sock_has_perm(sk, SOCKET__BIND);
>>>>> @@ -4585,7 +4586,9 @@ static int selinux_socket_bind(struct socket *sock, 
>>>>> struc>
>>>>>
>>>>>/* If PF_INET or PF_INET6, check name_bind permission for the 
>>>>> port. */
>>>>>family = sk->sk_family;
>>>>> -   if (family == PF_INET || family == PF_INET6) {
>>>>> +   family_sa = address->sa_family;
>>>>> +   if ((family == PF_INET || family == PF_INET6) &&
>>>>> +   (family_sa == PF_INET || family_sa == PF_INET6)) {
>>>>
>>>> Wouldn't this allow bypassing the name_bind permission check by passing in 
>>>> AF_UNSPEC?
>>>
>>> I believe these name_bind permission checkis skipped for AF_UNSPEC
>>> already, isn't it?  The only way the name_bind check would be
>>> triggered is if the source port, snum, was non-zero and I didn't think
>>> that was really legal for AF_UNSPEC/INADDR_ANY, is it?
>>
>> 1) What in inet_bind() prevents that from occurring?
>> 2) Regardless, what about the node_bind check?
> 
> Fair enough.  As mentioned above, perhaps the right fix is to move the
> address family ch

[PATCH] libsepol: cil: prevent stack buffer overflow in cil_expr_to_string

[Stephen Smalley]

Fix the test to prevent overflowing the stack buffer for
boolean expressions.

Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov>
---
 libsepol/cil/src/cil_tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libsepol/cil/src/cil_tree.c b/libsepol/cil/src/cil_tree.c
index 2abbb96c..1b04fe68 100644
--- a/libsepol/cil/src/cil_tree.c
+++ b/libsepol/cil/src/cil_tree.c
@@ -339,7 +339,7 @@ static int cil_expr_to_string(struct cil_list *expr, char 
**out)
int pos = 0;
 
cil_list_for_each(curr, expr) {
-   if (pos > COND_EXPR_MAXDEPTH) {
+   if (pos >= COND_EXPR_MAXDEPTH) {
rc = SEPOL_ERR;
goto exit;
}
-- 
2.14.3

Re: [PATCH] selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()

[Stephen Smalley]

On 05/08/2018 08:25 PM, Paul Moore wrote:
> On Tue, May 8, 2018 at 2:40 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
>> On 05/08/2018 01:05 PM, Paul Moore wrote:
>>> On Tue, May 8, 2018 at 10:05 AM, Alexey Kodanev
>>> <alexey.koda...@oracle.com> wrote:
>>>> Commit d452930fd3b9 ("selinux: Add SCTP support") breaks compatibility
>>>> with the old programs that can pass sockaddr_in with AF_UNSPEC and
>>>> INADDR_ANY to bind(). As a result, bind() returns EAFNOSUPPORT error.
>>>> It was found with LTP/asapi_01 test.
>>>>
>>>> Similar to commit 29c486df6a20 ("net: ipv4: relax AF_INET check in
>>>> bind()"), which relaxed AF_INET check for compatibility, add AF_UNSPEC
>>>> case to AF_INET and make sure that the address is INADDR_ANY.
>>>>
>>>> Also, in the end of selinux_socket_bind(), instead of adding AF_UNSPEC
>>>> to 'address->sa_family == AF_INET', verify AF_INET6 first.
>>>>
>>>> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
>>>> Signed-off-by: Alexey Kodanev <alexey.koda...@oracle.com>
>>>> ---
>>>>  security/selinux/hooks.c | 12 +---
>>>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>>
>>> Thanks for finding and reporting this regression.
>>>
>>> I think I would prefer to avoid having to duplicate the
>>> AF_UNSPEC/INADDR_ANY checking logic in the SELinux hook, even though
>>> it is a small bit of code and unlikely to change.  I'm wondering if it
>>> would be better to check both the socket and sockaddr address family
>>> in the main if conditional inside selinux_socket_bind(), what do you
>>> think?  Another option would be to go back to just checking the
>>> soackaddr address family; we moved away from that for a reason which
>>> escapes at the moment (code cleanliness?), but perhaps that was a
>>> mistake.
>>
>> We've always used the sk->sk_family there; it was only the recent code from 
>> Richard that started
>> using the socket address family.
> 
> Yes I know, I thought I was the one that suggested it at some point
> (I'll take the blame) ... although now that I'm looking at the git
> log, maybe I'm confusing it with something else.
> 
>>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>>> index 4cafe6a19167..a3789b167667 100644
>>> --- a/security/selinux/hooks.c
>>> +++ b/security/selinux/hooks.c
>>> @@ -4577,6 +4577,7 @@ static int selinux_socket_bind(struct socket *sock, 
>>> struc>
>>> {
>>>struct sock *sk = sock->sk;
>>>u16 family;
>>> +   u16 family_sa;
>>>int err;
>>>
>>>err = sock_has_perm(sk, SOCKET__BIND);
>>> @@ -4585,7 +4586,9 @@ static int selinux_socket_bind(struct socket *sock, 
>>> struc>
>>>
>>>/* If PF_INET or PF_INET6, check name_bind permission for the port. 
>>> */
>>>family = sk->sk_family;
>>> -   if (family == PF_INET || family == PF_INET6) {
>>> +   family_sa = address->sa_family;
>>> +   if ((family == PF_INET || family == PF_INET6) &&
>>> +   (family_sa == PF_INET || family_sa == PF_INET6)) {
>>
>> Wouldn't this allow bypassing the name_bind permission check by passing in 
>> AF_UNSPEC?
> 
> I believe these name_bind permission checkis skipped for AF_UNSPEC
> already, isn't it?  The only way the name_bind check would be
> triggered is if the source port, snum, was non-zero and I didn't think
> that was really legal for AF_UNSPEC/INADDR_ANY, is it?

1) What in inet_bind() prevents that from occurring?
2) Regardless, what about the node_bind check?

> 
>>>char *addrp;
>>>struct sk_security_struct *sksec = sk->sk_security;
>>>struct common_audit_data ad;
>>> @@ -4601,7 +4604,7 @@ static int selinux_socket_bind(struct socket *sock, 
>>> struc>
>>> * need to check address->sa_family as it is possible to have
>>> * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
>>> */
>>> -   switch (address->sa_family) {
>>> +   switch (family_sa) {
>>>case AF_INET:
>>>if (addrlen < sizeof(struct sockaddr_in))
>>>return -EINVAL;
>>>
>>>> di

Re: Loopback TCP connection

[Stephen Smalley]

On 04/27/2018 10:23 AM, Troels Arvin wrote:
> Hello,
> 
> RHEL/CentOS 7.4 was rather disastrous for Tomcat users, because lots of 
> things which used to work suddenly broke, due to a new SELinux policy for 
> Tomcat. RHEL 7.5 has fixed most of it, because a number of commits allowed 
> Tomcat to connect to database systems and other things:
> 
> https://github.com/fedora-selinux/selinux-policy-contrib/commit/cf1ac899006bed35c10c08a76adbbf8ce6e68443
> https://github.com/fedora-selinux/selinux-policy-contrib/commit/e67f46aec82a897218c879e5c92e6921407b9074
> ...
> 
> But I still have a Tomcat app which has run into SELinux-denials. The app 
> needs to send mails, so it tries to connect to port 25. I see a number of 
> ways this could be handled, but I would prefer the following combination:
> 
>  - adjust the policy, so that by default, Tomcat can allow to
>    port 25/tcp on the loopback interface
> 
>  - and add a boolean which allows Tomcat to connect to any port 25/tcp,
>    maybe something along the lines of
>    corenet_tcp_loopback_connect_smtp(tomcat_domain)
> 
> Before I create a Bugzilla case about this for Fedora/Red Hat, I have some 
> questions:
>  - Is it possible to selectively allow an application to connect to something 
> on the loopback-interface?
>  - Is the above proposal a good one, or am I overlooking something?

See:
https://github.com/SELinuxProject/selinux-kernel/issues/21
https://bugzilla.redhat.com/show_bug.cgi?id=1168044

ANN: SELinux userspace 2.8-rc3 release candidate

[Stephen Smalley]

A 2.8-rc3 release candidate for the SELinux userspace is now available at:
https://github.com/SELinuxProject/selinux/wiki/Releases

Please give it a test and let us know if there are any issues.

A draft of the release notes is available from the Releases page, as
is the full git log output and git shortlog output since the 2.7
release.  If there are further items we should mention or if something
should be amended in the release notes, let us know.
 
Thanks to all the contributors to this release candidate!
 
A shortlog of changes since the 2.8-rc2 release candidate is below.

Stephen Smalley (7):
  libsepol: remove unused function and type
  libselinux: fix build warning in save_booleans()
  libselinux: avcstat: fix build warning
  libselinux: audit2why: fix build warnings
  libsemanage: prevent string overflow on final paths
  libsepol: cil: prevent stack buffer overflow in cil_expr_to_string
  Update VERSION files to 2.8-rc3

Vit Mojzis (1):
  python/semanage/seobject.py: Fix undefined store check

Re: [PATCH] python/semanage/seobject.py: Fix undefined store check

[Stephen Smalley]

On 05/04/2018 07:51 AM, Petr Lautrbach wrote:
> From: Vit Mojzis 
> 
> self.store is always a string (actual store name or "") because of
> semanageRecords.__init__. Fix check for not defined store.
> 
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1559174#c3
> 
> Signed-off-by: Vit Mojzis 
> ---
>  python/semanage/seobject.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/python/semanage/seobject.py b/python/semanage/seobject.py
> index ac310ea6..c76dce85 100644
> --- a/python/semanage/seobject.py
> +++ b/python/semanage/seobject.py
> @@ -2651,7 +2651,7 @@ class booleanRecords(semanageRecords):
>  self.current_booleans = []
>  ptype = None
>  
> -if self.store is None or self.store == ptype:
> +if self.store == "" or self.store == ptype:
>  self.modify_local = True
>  else:
>  self.modify_local = False
> 

Applied.

Re: [PATCH 0/4] Fix build warnings with gcc 8

[Stephen Smalley]

On 05/03/2018 02:48 PM, Stephen Smalley wrote:
> I encountered a number of build warnings on the selinux userspace
> using gcc 8, which is the default now in F28 and rawhide. This fixes
> the ones that are treated as fatal errors by default.  There are still
> known warnings due to the flex skeleton and something to do with the
> python bindings, but those are not new.
> 
> Stephen Smalley (4):
>   libsepol: remove unused function and type
>   libselinux: fix build warning in save_booleans()
>   libselinux: avcstat: fix build warning
>   libselinux: audit2why: fix build warnings
> 
>  libselinux/src/audit2why.c | 2 +-
>  libselinux/src/booleans.c  | 4 +++-
>  libselinux/utils/avcstat.c | 3 ++-
>  libsepol/include/sepol/policydb/policydb.h | 3 ---
>  libsepol/src/policydb.c| 8 
>  5 files changed, 6 insertions(+), 14 deletions(-)

Applied.

[PATCH] libsemanage: prevent string overflow on final paths

[Stephen Smalley]

Verify that the final path does not exceed the size of the
buffer before copying.  This can only occur if an alternate
path for the policy root and/or the policy store root has been
specified and if the resulting path would exceed PATH_MAX. A
similar check is already applied by semanage_make_final().

Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov>
---
 libsemanage/src/semanage_store.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libsemanage/src/semanage_store.c b/libsemanage/src/semanage_store.c
index bce648c4..f1984c50 100644
--- a/libsemanage/src/semanage_store.c
+++ b/libsemanage/src/semanage_store.c
@@ -1597,7 +1597,12 @@ static int semanage_install_final_tmp(semanage_handle_t 
* sh)
/* skip genhomedircon if configured */
if (sh->conf->disable_genhomedircon &&
i == SEMANAGE_FC_HOMEDIRS) continue;
-   
+
+   if (strlen(dst) >= sizeof(fn)) {
+   ERR(sh, "Unable to compose the final paths.");
+   status = -1;
+   goto cleanup;
+   }
strcpy(fn, dst);
ret = semanage_mkpath(sh, dirname(fn));
if (ret < 0) {
-- 
2.14.3

Re: [PATCH] selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()

[Stephen Smalley]

On 05/08/2018 01:05 PM, Paul Moore wrote:
> On Tue, May 8, 2018 at 10:05 AM, Alexey Kodanev
>  wrote:
>> Commit d452930fd3b9 ("selinux: Add SCTP support") breaks compatibility
>> with the old programs that can pass sockaddr_in with AF_UNSPEC and
>> INADDR_ANY to bind(). As a result, bind() returns EAFNOSUPPORT error.
>> It was found with LTP/asapi_01 test.
>>
>> Similar to commit 29c486df6a20 ("net: ipv4: relax AF_INET check in
>> bind()"), which relaxed AF_INET check for compatibility, add AF_UNSPEC
>> case to AF_INET and make sure that the address is INADDR_ANY.
>>
>> Also, in the end of selinux_socket_bind(), instead of adding AF_UNSPEC
>> to 'address->sa_family == AF_INET', verify AF_INET6 first.
>>
>> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
>> Signed-off-by: Alexey Kodanev 
>> ---
>>  security/selinux/hooks.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> Thanks for finding and reporting this regression.
> 
> I think I would prefer to avoid having to duplicate the
> AF_UNSPEC/INADDR_ANY checking logic in the SELinux hook, even though
> it is a small bit of code and unlikely to change.  I'm wondering if it
> would be better to check both the socket and sockaddr address family
> in the main if conditional inside selinux_socket_bind(), what do you
> think?  Another option would be to go back to just checking the
> soackaddr address family; we moved away from that for a reason which
> escapes at the moment (code cleanliness?), but perhaps that was a
> mistake.

We've always used the sk->sk_family there; it was only the recent code from 
Richard that started
using the socket address family.

> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 4cafe6a19167..a3789b167667 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4577,6 +4577,7 @@ static int selinux_socket_bind(struct socket *sock, 
> struc>
> {
>struct sock *sk = sock->sk;
>u16 family;
> +   u16 family_sa;
>int err;
> 
>err = sock_has_perm(sk, SOCKET__BIND);
> @@ -4585,7 +4586,9 @@ static int selinux_socket_bind(struct socket *sock, 
> struc>
> 
>/* If PF_INET or PF_INET6, check name_bind permission for the port. */
>family = sk->sk_family;
> -   if (family == PF_INET || family == PF_INET6) {
> +   family_sa = address->sa_family;
> +   if ((family == PF_INET || family == PF_INET6) &&
> +   (family_sa == PF_INET || family_sa == PF_INET6)) {

Wouldn't this allow bypassing the name_bind permission check by passing in 
AF_UNSPEC?

>char *addrp;
>struct sk_security_struct *sksec = sk->sk_security;
>struct common_audit_data ad;
> @@ -4601,7 +4604,7 @@ static int selinux_socket_bind(struct socket *sock, 
> struc>
> * need to check address->sa_family as it is possible to have
> * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
> */
> -   switch (address->sa_family) {
> +   switch (family_sa) {
>case AF_INET:
>if (addrlen < sizeof(struct sockaddr_in))
>return -EINVAL;
> 
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 4cafe6a..649a3be 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -4602,10 +4602,16 @@ static int selinux_socket_bind(struct socket *sock, 
>> struct sockaddr *address, in
>>  * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
>>  */
>> switch (address->sa_family) {
>> +   case AF_UNSPEC:
>> case AF_INET:
>> if (addrlen < sizeof(struct sockaddr_in))
>> return -EINVAL;
>> addr4 = (struct sockaddr_in *)address;
>> +
>> +   if (address->sa_family == AF_UNSPEC &&
>> +   addr4->sin_addr.s_addr != htonl(INADDR_ANY))
>> +   return -EAFNOSUPPORT;
>> +
>> snum = ntohs(addr4->sin_port);
>> addrp = (char *)>sin_addr.s_addr;
>> break;
>> @@ -4681,10 +4687,10 @@ static int selinux_socket_bind(struct socket *sock, 
>> struct sockaddr *address, in
>> ad.u.net->sport = htons(snum);
>> ad.u.net->family = family;
>>
>> -   if (address->sa_family == AF_INET)
>> -   ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
>> -   else
>> +   if (address->sa_family == AF_INET6)
>> ad.u.net->v6info.saddr = addr6->sin6_addr;
>> +   else
>> +   ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
>>
>> err = avc_has_perm(_state,
>>

Re: Last call for selinux userspace 2.8 release

[Stephen Smalley]

On 05/04/2018 09:26 AM, Dominick Grift wrote:
> On Fri, May 04, 2018 at 09:08:36AM -0400, Stephen Smalley wrote:
>> On 05/04/2018 03:55 AM, Jason Zaman wrote:
>>> On Thu, May 03, 2018 at 10:52:24AM -0400, Stephen Smalley wrote:
>>>> Hi,
>>>>
>>>> If you have encountered any unreported problems with the 2.8-rcX releases 
>>>> or have any
>>>> pending patches you believe should be included in the 2.8 release, please 
>>>> post them soon.
>>>
>>> the rc2 release has been fine for me for several days now. And I havent
>>> heard any issues from any gentoo users either so we're probably good to
>>> go. -rc1 failed to boot properly for me because some important things in
>>> /run or /dev didnt get labeled but that was fixed in rc2.
>>
>> Hmm...I'd like to understand that better. The change was verifying 
>> file_contexts when using restorecon,
>> which was reverted in -rc2.  But the fact that it prevented labeling files 
>> in -rc1 means that either
>> you have a bug in your file_contexts configuration or there is some other 
>> bug there.
> 
> If it cannot validate_context then it will be unhappy:
> 
> [root@julius ~]# dnf history info last
> Transaction ID : 364
> Begin time : Fri 04 May 2018 01:12:36 PM CEST
> Begin rpmdb: 1404:e739a03c49fec80ed41a1ea4c599d8f877b01d76
> End time   : Fri 04 May 2018 01:14:01 PM CEST (85 seconds)
> End rpmdb  : 1404:27bd40dce7edbf226ffad80f482cd75231f1b6ab **
> User   : kcinimod 
> Return-Code: Success
> Command Line   : update --exclude efi-filesystem
> Transaction performed with:
> Installed dnf-2.7.5-12.fc29.noarch @rawhide
> Installed rpm-4.14.1-8.fc28.x86_64 @tmp-rawhide
>   Packages Altered:
>   Upgraded cockpit-166-1.fc29.x86_64  @rawhide
> ... snip ...
> Scriptlet output:
>1 restorecon: /etc/selinux/dssp2-standard/contexts/files/file_contexts: 
> has invalid context sys.id:sys.role:files.generic_boot.boot_file:s0
>   2 restorecon: /etc/selinux/dssp2-standard/contexts/files/file_contexts: 
> has invalid context sys.id:sys.role:files.generic_boot.boot_file:s0
>  3 restorecon: 
> /etc/selinux/dssp2-standard/contexts/files/file_contexts: has invalid context 
> sys.id:sys.role:files.generic_boot.boot_file:s0
>   4 restorecon: 
> /etc/selinux/dssp2-standard/contexts/files/file_contexts: has invalid context 
> sys.id:sys.role:files.generic_boot.boot_file:s0
>  5 restorecon: 
> /etc/selinux/dssp2-standard/contexts/files/file_contexts: has invalid context 
> sys.id:sys.role:files.generic_boot.boot_file:s0

So, just to be clear: these contexts are in fact valid but the lack of 
permission to use the /sys/fs/selinux/context interface (for 
security_check_context) causes it to think the context is invalid and therefore 
fails?  If so, then 
that makes sense and would be another reason for reverting that change.  In any 
case, -rc2 should have the fix.

Re: Last call for selinux userspace 2.8 release

[Stephen Smalley]

On 05/04/2018 03:55 AM, Jason Zaman wrote:
> On Thu, May 03, 2018 at 10:52:24AM -0400, Stephen Smalley wrote:
>> Hi,
>>
>> If you have encountered any unreported problems with the 2.8-rcX releases or 
>> have any
>> pending patches you believe should be included in the 2.8 release, please 
>> post them soon.
> 
> the rc2 release has been fine for me for several days now. And I havent
> heard any issues from any gentoo users either so we're probably good to
> go. -rc1 failed to boot properly for me because some important things in
> /run or /dev didnt get labeled but that was fixed in rc2.

Hmm...I'd like to understand that better. The change was verifying 
file_contexts when using restorecon,
which was reverted in -rc2.  But the fact that it prevented labeling files in 
-rc1 means that either
you have a bug in your file_contexts configuration or there is some other bug 
there.

> 
>> Also, let us know of any additions or changes that should be made to the 
>> release notes;
>> the current draft is as follows.
>>
>> User-visible changes:
>>
>> * semanage fcontext -l now also lists home directory entries from
>> file_contexts.homedirs.
>>
>> * semodule can now enable or disable multiple modules in the same
>> operation by specifying a list of modules after -e or -d, making them
>> consistent with the -i/u/r/E options.
>>
>> * CIL now supports multiple declarations of types, attributes, and
>> (non-conflicting) object contexts (e.g. genfscon), enabled via the -m
>> or --multiple-decls option to secilc.
>>
>> * libsemanage no longer deletes the tmp directory if there is an error
>> while committing the policy transaction, so that any temporary files
>> can be further inspected for debugging purposes (e.g. to examine a
>> particular line of the generated CIL module).  The tmp directory will
>> be deleted upon the next transaction, so no manual removal is needed.
>>
>> * Support was added for SCTP portcon statements. The corresponding
>> kernel support was introduced in Linux 4.17, and is only active if the
>> extended_socket_class policy capability is enabled in the policy.
> 
> Perhaps also note that the sctp stuff is in refpolicy and this 2.8
> release is required to compile it.
> 
> I tried doing a release of the gentoo policy (we merge from HEAD fairly
> frequently not only the big releases) and it fails to compile. I will
> add the sctp stuff back into gentoo's policy later then make the
> policies require >=2.8.
> 
> -- Jason
> 
>> * sepol_polcap_getnum/name() were exported as part of the shared libsepol
>> interface, initially for use by setools4.
>>
>> * semodule_deps was removed since it has long been broken and is not useful
>> for CIL modules.
>>
>> Packaging-relevant changes:
>>
>> * When overriding PREFIX, BINDIR, SBINDIR, SHLIBDIR, LIBEXECDIR, etc.,
>> DESTDIR has to be removed from the definition. For example on Arch
>> Linux, SBINDIR="${pkgdir}/usr/bin" was changed to SBINDIR="/usr/bin".
>>
>> * Defining variable LIBSEPOLA (to /usr/lib/libsepol.a, for example) is
>> no longer mandatory (thanks to the switch to "-l:libsepol.a" in
>> Makefiles).
>>
>> * PYSITEDIR has been renamed PYTHONLIBDIR (and its definition changed).
>>
>> * selinux-gui (i.e. system-config-selinux GUI application) is now
>> compatible with Python 3. Doing this required migrating away from
>> PyGTK to the supported PyGI library. This means that selinux-gui now
>> depends on python-gobject, Gtk+ 3 and selinux-python. It no longer
>> requires PyGtk or Python 2.
> 

Re: Last call for selinux userspace 2.8 release

[Stephen Smalley]

On 05/04/2018 08:19 AM, Dominick Grift wrote:
> On Thu, May 03, 2018 at 10:52:24AM -0400, Stephen Smalley wrote:
>> Hi,
>>
>> If you have encountered any unreported problems with the 2.8-rcX releases or 
>> have any
>> pending patches you believe should be included in the 2.8 release, please 
>> post them soon.
>> Also, let us know of any additions or changes that should be made to the 
>> release notes;
>> the current draft is as follows.
>>
>> User-visible changes:
> 
> One might see processes "validate_context" where they didnt before
> 
> Generally processes that use lgetfilecon/lsetfilecon i suspect (like lvm, 
> various systemd components etc)

That should no longer be true as of -rc2 since I reverted the libselinux: 
verify file_contexts when using restorecon change.

> 
>>
>> * semanage fcontext -l now also lists home directory entries from
>> file_contexts.homedirs.
>>
>> * semodule can now enable or disable multiple modules in the same
>> operation by specifying a list of modules after -e or -d, making them
>> consistent with the -i/u/r/E options.
>>
>> * CIL now supports multiple declarations of types, attributes, and
>> (non-conflicting) object contexts (e.g. genfscon), enabled via the -m
>> or --multiple-decls option to secilc.
>>
>> * libsemanage no longer deletes the tmp directory if there is an error
>> while committing the policy transaction, so that any temporary files
>> can be further inspected for debugging purposes (e.g. to examine a
>> particular line of the generated CIL module).  The tmp directory will
>> be deleted upon the next transaction, so no manual removal is needed.
>>
>> * Support was added for SCTP portcon statements. The corresponding
>> kernel support was introduced in Linux 4.17, and is only active if the
>> extended_socket_class policy capability is enabled in the policy.
>>
>> * sepol_polcap_getnum/name() were exported as part of the shared libsepol
>> interface, initially for use by setools4.
>>
>> * semodule_deps was removed since it has long been broken and is not useful
>> for CIL modules.
>>
>> Packaging-relevant changes:
>>
>> * When overriding PREFIX, BINDIR, SBINDIR, SHLIBDIR, LIBEXECDIR, etc.,
>> DESTDIR has to be removed from the definition. For example on Arch
>> Linux, SBINDIR="${pkgdir}/usr/bin" was changed to SBINDIR="/usr/bin".
>>
>> * Defining variable LIBSEPOLA (to /usr/lib/libsepol.a, for example) is
>> no longer mandatory (thanks to the switch to "-l:libsepol.a" in
>> Makefiles).
>>
>> * PYSITEDIR has been renamed PYTHONLIBDIR (and its definition changed).
>>
>> * selinux-gui (i.e. system-config-selinux GUI application) is now
>> compatible with Python 3. Doing this required migrating away from
>> PyGTK to the supported PyGI library. This means that selinux-gui now
>> depends on python-gobject, Gtk+ 3 and selinux-python. It no longer
>> requires PyGtk or Python 2.
> 

Re: [RFC PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/15/2018 04:25 AM, Richard Haines via Selinux wrote:
> Add binder tests. See tests/binder/test_binder.c for details on
> message flows to test security_binder*() functions.
> 
> Signed-off-by: Richard Haines 
> ---
>  README.md   |   8 +
>  defconfig   |   8 +
>  policy/Makefile |   2 +-
>  policy/test_binder.te   |  83 +++
>  tests/Makefile  |   2 +-
>  tests/binder/Makefile   |   7 +
>  tests/binder/check_binder.c |  80 +++
>  tests/binder/test   | 131 +++
>  tests/binder/test_binder.c  | 543 
> 
>  9 files changed, 862 insertions(+), 2 deletions(-)
>  create mode 100644 policy/test_binder.te
>  create mode 100644 tests/binder/Makefile
>  create mode 100644 tests/binder/check_binder.c
>  create mode 100644 tests/binder/test
>  create mode 100644 tests/binder/test_binder.c
> 
> diff --git a/README.md b/README.md
> index c9f3b2b..60a249e 100644
> --- a/README.md
> +++ b/README.md
> @@ -141,6 +141,14 @@ directory or you can follow these broken-out steps:
>  The broken-out steps allow you to run the tests multiple times without
>  loading policy each time.
>  
> +Note that if leaving the test policy in-place for further testing, the
> +policy build process changes a boolean:
> +   On policy load:   setsebool allow_domain_fd_use=0
> +   On policy unload: setsebool allow_domain_fd_use=1
> +The consequence of this is that after a system reboot, the boolean
> +defaults to true. Therefore if running the fdreceive or binder tests,
> +reset the boolean to false, otherwise some tests will fail.

This isn't accurate - we aren't doing setsebool -P so the boolean change is not 
persistent across
reboots.  It will persist across policy reloads however because the kernel 
preserves booleans across
policy reloads.

> +
>  4) Review the test results.
>  
>  As each test script is run, the name of the script will be displayed followed
> diff --git a/defconfig b/defconfig
> index 7dce8bc..dc6ef30 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -51,3 +51,11 @@ CONFIG_CRYPTO_USER=m
>  # This is enabled to test overlayfs SELinux integration.
>  # It is not required for SELinux operation itself.
>  CONFIG_OVERLAY_FS=m
> +
> +# Android binder implementations.
> +# These are enabled to test the binder controls in
> +# tests/binder; they are not required for SELinux operation itself.
> +CONFIG_ANDROID=y
> +CONFIG_ANDROID_BINDER_IPC=y
> +CONFIG_ANDROID_BINDER_DEVICES="binder"
> +# CONFIG_ANDROID_BINDER_IPC_SELFTEST is not set

I don't think we need the last line.

> diff --git a/policy/Makefile b/policy/Makefile
> index 8ed5e46..5a9d411 100644
> --- a/policy/Makefile
> +++ b/policy/Makefile
> @@ -25,7 +25,7 @@ TARGETS = \
>   test_task_getsid.te test_task_setpgid.te test_task_setsched.te \
>   test_transition.te test_inet_socket.te test_unix_socket.te \
>   test_mmap.te test_overlayfs.te test_mqueue.te test_mac_admin.te \
> - test_ibpkey.te test_atsecure.te
> + test_ibpkey.te test_atsecure.te test_binder.te

Likely need to make this conditional on the binder class being defined in the 
policy;
see similar logic for e.g. cap_userns, icmp_socket, etc.  Otherwise policy 
won't build
on earlier Fedora/RHEL before definition of the binder class.

>  
>  ifeq ($(shell [ $(POL_VERS) -ge 24 ] && echo true),true)
>  TARGETS += test_bounds.te
> diff --git a/policy/test_binder.te b/policy/test_binder.te
> new file mode 100644
> index 000..c4ad2ae
> --- /dev/null
> +++ b/policy/test_binder.te
> @@ -0,0 +1,83 @@
> +
> +attribute binderdomain;
> +
> +#
> +## Manager 
> ###
> +#
> +type test_binder_mgr_t;
> +domain_type(test_binder_mgr_t)
> +unconfined_runs_test(test_binder_mgr_t)
> +typeattribute test_binder_mgr_t testdomain;
> +typeattribute test_binder_mgr_t binderdomain;
> +allow test_binder_mgr_t self:binder { set_context_mgr call };
> +allow test_binder_mgr_t device_t:chr_file { ioctl open read write map };

Wondering if we should define a .fc file with /dev/binder and a proper 
binder_device_t type
and restorecon it before the test.  But not clear it is worth it.  Never mind.

> +allow test_binder_mgr_t self:capability { sys_nice };

Needed or just to suppress noise in the audit?

> +allow test_binder_client_t test_binder_mgr_t:fd use;
> +
> +#
> +# Client 
> +#
> +type test_binder_client_t;
> +domain_type(test_binder_client_t)
> +unconfined_runs_test(test_binder_client_t)
> +typeattribute test_binder_client_t testdomain;
> +typeattribute test_binder_client_t binderdomain;
> +allow test_binder_client_t self:binder { call };
> +allow test_binder_client_t test_binder_mgr_t:binder { call transfer 
> impersonate };

Are you actually exercising impersonate?  I largely didn't expect it to ever be 
used in Android itself,
just 

Re: Anyone using the SELinux test suite on Fedora 28?

[Stephen Smalley]

On 05/15/2018 08:28 AM, Stephen Smalley wrote:
> On 05/14/2018 08:10 PM, Casey Schaufler wrote:
>> On 5/14/2018 4:48 PM, Stephen Smalley wrote:
>>> It's been running fine for me. Maybe you just need to clean your tree and 
>>> do a fresh make test.
>>
>> Did that first thing.
>>
>> Digging down, I find that the "make -C policy load" is failing.
>>
>> make[1]: Leaving directory 
>> '/home/cschaufler/SELinux/selinux-testsuite/policy/test_policy'
>> # General policy load
>> /usr/sbin/semodule -i test_policy/test_policy.pp
>> neverallow check failed at 
>> /var/lib/selinux/targeted/tmp/modules/100/base/cil:4703
>>   (neverallow base_typeattr_6 base_typeattr_7 (process (fork transition 
>> sigchld sigkill sigstop signull signal ptrace getsched setsched getsession 
>> getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure 
>> siginh setrlimit rlimitinh dyntransition setcurrent execmem execstack 
>> execheap setkeycreate setsockcreate getrlimit)))
>> 
>> allow at /var/lib/selinux/targeted/tmp/modules/400/test_policy/cil:2565
>>   (allow test_create_no_t unconfined_t (process (sigchld)))
>> 
>> allow at /var/lib/selinux/targeted/tmp/modules/400/test_policy/cil:2569
>>   (allow test_create_no_t self (process (transition sigchld sigkill 
>> sigstop signull signal ptrace getsched setsched getsession getpgid setpgid 
>> getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit 
>> rlimitinh dyntransition setcurrent execmem execstack execheap setkeycreate 
>> setsockcreate getrlimit)))
>> 
>> allow at /var/lib/selinux/targeted/tmp/modules/400/test_policy/cil:2606
>>   (allow test_create_no_t self (process (setexec)))
>> 
>> allow at /var/lib/selinux/targeted/tmp/modules/400/test_policy/cil:2634
>>   (allow test_create_d sysadm_t (process (sigchld)))
>>
>> I bet the reason it's doing this is obvious. Just not to me.
> 
> Add or uncomment expand-check = 0 in /etc/selinux/semanage.conf.
> That's noted in the README but used to be the default in Fedora (changed in 
> 28).

Also, just FYI, expand-check controls whether neverallow and type bounds 
checking is performed when the policy
is linked/expanded.  The test policy necessarily violates some of these policy 
assertions in order to test the
kernel functionality, and thus we have to disable the userspace checking when 
installing the test policy.  Fedora
used to disable this checking anyway (except when the policy is built as a 
package) because it was a) slow and
b) could prevent users from installing local policy modules that would violate 
these assertions (but might be
necessary to fix some issue they had).

> 
>>
>>> On Mon, May 14, 2018, 7:37 PM Casey Schaufler <ca...@schaufler-ca.com 
>>> <mailto:ca...@schaufler-ca.com>> wrote:
>>>
>>> Has anyone had success with the SELinux test suite on Fedora 28?
>>> I find the chcon and newrole are unhappy with the contexts used
>>> in the suite.
>>>
>>>
>>
> 

Re: [RFC PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/15/2018 09:36 AM, Stephen Smalley wrote:
> On 05/15/2018 04:25 AM, Richard Haines via Selinux wrote:
>> Add binder tests. See tests/binder/test_binder.c for details on
>> message flows to test security_binder*() functions.
>>
>> Signed-off-by: Richard Haines <richard_c_hai...@btinternet.com>
>> ---
>>  README.md   |   8 +
>>  defconfig   |   8 +
>>  policy/Makefile |   2 +-
>>  policy/test_binder.te   |  83 +++
>>  tests/Makefile  |   2 +-
>>  tests/binder/Makefile   |   7 +
>>  tests/binder/check_binder.c |  80 +++
>>  tests/binder/test   | 131 +++
>>  tests/binder/test_binder.c  | 543 
>> 
>>  9 files changed, 862 insertions(+), 2 deletions(-)
>>  create mode 100644 policy/test_binder.te
>>  create mode 100644 tests/binder/Makefile
>>  create mode 100644 tests/binder/check_binder.c
>>  create mode 100644 tests/binder/test
>>  create mode 100644 tests/binder/test_binder.c
>>
>> diff --git a/README.md b/README.md
>> index c9f3b2b..60a249e 100644
>> --- a/README.md
>> +++ b/README.md
>> @@ -141,6 +141,14 @@ directory or you can follow these broken-out steps:
>>  The broken-out steps allow you to run the tests multiple times without
>>  loading policy each time.
>>  
>> +Note that if leaving the test policy in-place for further testing, the
>> +policy build process changes a boolean:
>> +   On policy load:   setsebool allow_domain_fd_use=0
>> +   On policy unload: setsebool allow_domain_fd_use=1
>> +The consequence of this is that after a system reboot, the boolean
>> +defaults to true. Therefore if running the fdreceive or binder tests,
>> +reset the boolean to false, otherwise some tests will fail.
> 
> This isn't accurate - we aren't doing setsebool -P so the boolean change is 
> not persistent across
> reboots.  It will persist across policy reloads however because the kernel 
> preserves booleans across
> policy reloads.

Sorry, never mind - I misread the text above.  You are correct.

> 
>> +
>>  4) Review the test results.
>>  
>>  As each test script is run, the name of the script will be displayed 
>> followed
>> diff --git a/defconfig b/defconfig
>> index 7dce8bc..dc6ef30 100644
>> --- a/defconfig
>> +++ b/defconfig
>> @@ -51,3 +51,11 @@ CONFIG_CRYPTO_USER=m
>>  # This is enabled to test overlayfs SELinux integration.
>>  # It is not required for SELinux operation itself.
>>  CONFIG_OVERLAY_FS=m
>> +
>> +# Android binder implementations.
>> +# These are enabled to test the binder controls in
>> +# tests/binder; they are not required for SELinux operation itself.
>> +CONFIG_ANDROID=y
>> +CONFIG_ANDROID_BINDER_IPC=y
>> +CONFIG_ANDROID_BINDER_DEVICES="binder"
>> +# CONFIG_ANDROID_BINDER_IPC_SELFTEST is not set
> 
> I don't think we need the last line.
> 
>> diff --git a/policy/Makefile b/policy/Makefile
>> index 8ed5e46..5a9d411 100644
>> --- a/policy/Makefile
>> +++ b/policy/Makefile
>> @@ -25,7 +25,7 @@ TARGETS = \
>>  test_task_getsid.te test_task_setpgid.te test_task_setsched.te \
>>  test_transition.te test_inet_socket.te test_unix_socket.te \
>>  test_mmap.te test_overlayfs.te test_mqueue.te test_mac_admin.te \
>> -test_ibpkey.te test_atsecure.te
>> +test_ibpkey.te test_atsecure.te test_binder.te
> 
> Likely need to make this conditional on the binder class being defined in the 
> policy;
> see similar logic for e.g. cap_userns, icmp_socket, etc.  Otherwise policy 
> won't build
> on earlier Fedora/RHEL before definition of the binder class.
> 
>>  
>>  ifeq ($(shell [ $(POL_VERS) -ge 24 ] && echo true),true)
>>  TARGETS += test_bounds.te
>> diff --git a/policy/test_binder.te b/policy/test_binder.te
>> new file mode 100644
>> index 000..c4ad2ae
>> --- /dev/null
>> +++ b/policy/test_binder.te
>> @@ -0,0 +1,83 @@
>> +
>> +attribute binderdomain;
>> +
>> +#
>> +## Manager 
>> ###
>> +#
>> +type test_binder_mgr_t;
>> +domain_type(test_binder_mgr_t)
>> +unconfined_runs_test(test_binder_mgr_t)
>> +typeattribute test_binder_mgr_t testdomain;
>> +typeattribute test_binder_mgr_t binderdomain;
>> +allow test_binder_mgr_t self:binder { set_context_mgr call };
>> +allow test_binder_mgr_t device_t:chr_file { ioctl open read write map };
> 
> Wonder

Re: [RFC PATCH 0/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/15/2018 04:25 AM, Richard Haines via Selinux wrote:
> Not sure how useful this is but saw [1] and thought I'll have a go out
> of idle curiosity.

I haven't looked at the code yet but I'm in favor of adding it - this should
help prevent regressions in the binder SELinux checks in upstream kernels.

> 
> I've only tested on Fedora 27 with kernel-4.16.3-200.fc27.x86_64
> 
> Use ./test -v to see the flow of binder info
> 
> I just added the following to the standard kernel-x86_64.config:
> CONFIG_ANDROID_BINDER_DEVICES="binder"
> CONFIG_ANDROID_BINDER_IPC=y
> # CONFIG_ANDROID_BINDER_IPC_SELFTEST is not set
> 
> [1] https://github.com/SELinuxProject/selinux-testsuite/issues/27
> 
> Richard Haines (1):
>   selinux-testsuite: Add binder tests
> 
>  README.md   |   8 +
>  defconfig   |   8 +
>  policy/Makefile |   2 +-
>  policy/test_binder.te   |  83 +++
>  tests/Makefile  |   2 +-
>  tests/binder/Makefile   |   7 +
>  tests/binder/check_binder.c |  80 +++
>  tests/binder/test   | 131 +++
>  tests/binder/test_binder.c  | 543 
> 
>  9 files changed, 862 insertions(+), 2 deletions(-)
>  create mode 100644 policy/test_binder.te
>  create mode 100644 tests/binder/Makefile
>  create mode 100644 tests/binder/check_binder.c
>  create mode 100644 tests/binder/test
>  create mode 100644 tests/binder/test_binder.c
> 

Re: [PATCH 00/23] LSM: Full security module stacking

[Stephen Smalley]

On 05/14/2018 05:31 PM, Casey Schaufler wrote:
> On 5/14/2018 1:07 PM, Stephen Smalley wrote:
>> On 05/14/2018 03:52 PM, Stephen Smalley wrote:
>>> On 05/10/2018 08:30 PM, Casey Schaufler wrote:
>>>> Subject: [PATCH 00/23] LSM: Full security module stacking
>>>>
>>>> Here it is, the whole nine yards, broken into mostly
>>>> review friendly pieces. I believe that it would make
>>>> a good deal of sense to take this in two bites, with
>>>> the infrastructure managed blobs going first and the
>>>> secid conversion coming later. I hope there will be some
>>>> debate around that.
>>>>
>>>> The blob management part is pretty clean by now. I
>>>> welcome serious review on that. The secid part is more
>>>> wobbly, but I am convinced that it's the right direction
>>>> if not perhaps always the best possible implementation.
>>>> AppArmor in in the process of a major overhaul, and that
>>>> slowed me down a bit as I had to do new work to convert
>>>> it to use the new mechanisms.
>>>>
>>>> I had experimented with secid "tokens" in the hope of
>>>> minimizing API changes. That doesn't work. Changing
>>>> the APIs to use a struct secids pointer in place of a
>>>> u32 is brutal to the diffstat, but reduces the amount
>>>> of active code that has to change, and really makes
>>>> data management easier.
>>>>
>>>> If there are two possible ways to do a thing you will
>>>> find them both in the networking code. AF_UNIX, netfilter,
>>>> SO_PEERSEC and netlabel each has its own clever ways
>>>> to manipulate security information. I think I nailed
>>>> them all, but I'm not betting more than a beer on it.
>>>>
>>>> There could be issues in the audit code, although nothing
>>>> jumped out immediately. The same goes for the integrity
>>>> subsystem. I haven't tried Infiniband or very many
>>>> filesystem types that don't com standard with Fedora or
>>>> Ubuntu.
>>>>
>>>> I have fixed everything I've found. If you find something
>>>> (please look!) let me know.
>>>>
>>>> Tested primarily on virtual machines.
>>>>Fedora 25-27 - SELinux, Smack and the two together
>>>>Ubuntu 17.04 - AppArmor and AppArmor + Smack
>>>>
>>>> The SELinux test suite completes successfully unless
>>>> you add in Smack, in which case it fails where you would
>>>> expect it to due to the different use models for netlabel.
>>>> Smack tests work as well. AppArmor was tested by booting
>>>> Ubuntu, but not beyond.
>>> Getting this during boot with CONFIG_KASAN=y and SELinux+Smack stacked:
>>>
>>> [   83.809008] 
>>> ==
>>> [   83.809046] BUG: KASAN: use-after-free in string+0xab/0x180
>>> [   83.809051] Read of size 1 at addr 8803bb3ad508 by task systemd/1
>>>
>>> [   83.809062] CPU: 3 PID: 1 Comm: systemd Not tainted 4.17.0-rc3+ #41
>>> [   83.809066] Call Trace:
>>> [   83.809072]  dump_stack+0x9a/0xec
>>> [   83.809079]  print_address_description+0x65/0x22e
>>> [   83.809084]  ? string+0xab/0x180
>>> [   83.809087]  kasan_report.cold.6+0xac/0x2f4
>>> [   83.809095]  ? string+0xab/0x180
>>> [   83.809101]  ? widen_string+0x160/0x160
>>> [   83.809107]  ? __kasan_slab_free+0x125/0x170
>>> [   83.809110]  ? kfree+0xe5/0x2f0
>>> [   83.809114]  ? security_inode_getsecctx+0x20b/0x240
>>> [   83.809123]  ? vsnprintf+0x211/0x780
>>> [   83.809130]  ? pointer+0x560/0x560
>>> [   83.809137]  ? kasprintf+0x96/0xc0
>>> [   83.809141]  ? rcu_read_lock_sched_held+0x8f/0xa0
>>> [   83.809145]  ? __kmalloc_track_caller+0x2d7/0x330
>>> [   83.809152]  ? kvasprintf+0x8d/0x120
>>> [   83.809157]  ? bust_spinlocks+0x50/0x50
>>> [   83.809164]  ? mark_held_locks+0x8b/0xb0
>>> [   83.809173]  ? kasprintf+0x96/0xc0
>>> [   83.809177]  ? kvasprintf_const+0xb0/0xb0
>>> [   83.809184]  ? strlen+0x1f/0x40
>>> [   83.809194]  ? security_inode_getsecctx+0x101/0x240
>>> [   83.809200]  ? security_socket_getpeersec_dgram+0x90/0x90
>>> [   83.809204]  ? selinux_secctx_to_secid+0x20/0x20
>>> [   83.809209]  ? trace_hardirqs_on_caller+0x17f/0x260
>>> [   83.809215]  ? __lockdep_init_map+0x86/0x230
>>> [   83.809

Re: Anyone using the SELinux test suite on Fedora 28?

[Stephen Smalley]

On 05/14/2018 08:10 PM, Casey Schaufler wrote:
> On 5/14/2018 4:48 PM, Stephen Smalley wrote:
>> It's been running fine for me. Maybe you just need to clean your tree and do 
>> a fresh make test.
> 
> Did that first thing.
> 
> Digging down, I find that the "make -C policy load" is failing.
> 
> make[1]: Leaving directory 
> '/home/cschaufler/SELinux/selinux-testsuite/policy/test_policy'
> # General policy load
> /usr/sbin/semodule -i test_policy/test_policy.pp
> neverallow check failed at 
> /var/lib/selinux/targeted/tmp/modules/100/base/cil:4703
>   (neverallow base_typeattr_6 base_typeattr_7 (process (fork transition 
> sigchld sigkill sigstop signull signal ptrace getsched setsched getsession 
> getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure 
> siginh setrlimit rlimitinh dyntransition setcurrent execmem execstack 
> execheap setkeycreate setsockcreate getrlimit)))
> 
> allow at /var/lib/selinux/targeted/tmp/modules/400/test_policy/cil:2565
>   (allow test_create_no_t unconfined_t (process (sigchld)))
> 
> allow at /var/lib/selinux/targeted/tmp/modules/400/test_policy/cil:2569
>   (allow test_create_no_t self (process (transition sigchld sigkill 
> sigstop signull signal ptrace getsched setsched getsession getpgid setpgid 
> getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit 
> rlimitinh dyntransition setcurrent execmem execstack execheap setkeycreate 
> setsockcreate getrlimit)))
> 
> allow at /var/lib/selinux/targeted/tmp/modules/400/test_policy/cil:2606
>   (allow test_create_no_t self (process (setexec)))
> 
> allow at /var/lib/selinux/targeted/tmp/modules/400/test_policy/cil:2634
>   (allow test_create_d sysadm_t (process (sigchld)))
> 
> I bet the reason it's doing this is obvious. Just not to me.

Add or uncomment expand-check = 0 in /etc/selinux/semanage.conf.
That's noted in the README but used to be the default in Fedora (changed in 28).

> 
>> On Mon, May 14, 2018, 7:37 PM Casey Schaufler <ca...@schaufler-ca.com 
>> <mailto:ca...@schaufler-ca.com>> wrote:
>>
>> Has anyone had success with the SELinux test suite on Fedora 28?
>> I find the chcon and newrole are unhappy with the contexts used
>> in the suite.
>>
>>
> 

Re: Re: [RFC PATCH] selinux-testsuite: check the "expand-check" setting in semanage.conf

[Stephen Smalley]

On 05/16/2018 03:31 AM, Petr Lautrbach wrote:
> On Tue, May 15, 2018 at 05:03:42PM -0400, Paul Moore wrote:
>> From: Paul Moore 
>>
>> If expand-check is non-zero in semanage.conf the policy load will likely 
>> fail,
>> try to provide a more helpful error to users running the tests.
>>
>> Signed-off-by: Paul Moore 
>> ---
>>  policy/Makefile |   12 ++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/policy/Makefile b/policy/Makefile
>> index 8ed5e46..cc022e3 100644
>> --- a/policy/Makefile
>> +++ b/policy/Makefile
>> @@ -87,6 +87,14 @@ build: $(BUILD_TARGET)
>>  load: $(LOAD_TARGET)
>>  unload: $(UNLOAD_TARGET)
>>  
>> +expand_check:
>> +# Test for "expand-check = 0" in /etc/selinux/semanage.conf
>> +@cat /etc/selinux/semanage.conf | \
>> +sed -n 's/^[ \t]*expand-check[ \t]*=[ \t]*0/OK/p' | \
>> +grep -q "OK" || \
>> +(echo "ERROR: set 'expand-check = 0' in semanage.conf"; \
>> + /bin/false)
>> +
> 
> You can use grep directly:
> 
> + grep -q '^[ \t]*expand-check[ \t]*=[ \t]*0' /etc/selinux/semanage.conf || \
> +  (echo "ERROR: set 'expand-check = 0' in semanage.conf";
> +  /bin/false)

And you should probably put the full path for the file in the error message.

> 
>>  build_rhel: $(TARGETS)
>>  # RHEL specific policy build
>>  $(MAKE) -C redhat/$(RHEL_VERS) all
>> @@ -103,11 +111,11 @@ build_general: $(TARGETS)
>>  echo "ERROR: You must have selinux-policy-devel installed."; \
>>  fi
>>  
>> -load_rhel: all
>> +load_rhel: expand_check all
>>  # RHEL specific policy load
>>  $(MAKE) -C redhat/$(RHEL_VERS) load
>>  
>> -load_general: all
>> +load_general: expand_check all
>>  # General policy load
>>  @-/usr/sbin/setsebool allow_domain_fd_use=0
>>  $(SEMODULE) -i test_policy/test_policy.pp
>>
>>

Re: [RFC PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/15/2018 01:34 PM, Richard Haines wrote:
> On Tue, 2018-05-15 at 12:56 -0400, Stephen Smalley wrote:
>> On 05/15/2018 12:38 PM, Stephen Smalley wrote:
>>> On 05/15/2018 09:43 AM, Stephen Smalley wrote:
>>>> On 05/15/2018 09:36 AM, Stephen Smalley wrote:
>>>>> This test is failing for me (with or without -v):
>>>>> # ./test -v
>>>>> 1..6
>>>>> Manager PID: 5608 Process context:
>>>>>   unconfined_u:unconfined_r:test_binder_mgr_t:s0-
>>>>> s0:c0.c1023
>>>>> Client PID: 5609 Process context:
>>>>>   unconfined_u:unconfined_r:test_binder_client_t:s0-
>>>>> s0:c0.c1023
>>>>> Client read_consumed: 28
>>>>> Manager read_consumed: 72
>>>>> Client command: BR_NOOP
>>>>> Manager command: BR_NOOP
>>>>> Client command: BR_INCREFS
>>>>> Manager command: BR_TRANSACTION
>>>>> Client command: BR_TRANSACTION_COMPLETE
>>>>> BR_TRANSACTION data:
>>>>>   handle: 0
>>>>>   cookie: 0
>>>>>   code: 0
>>>>>   flag: TF_ACCEPT_FDS
>>>>>   sender pid: 5609
>>>>>   sender euid: 0
>>>>>   data_size: 24
>>>>>   offsets_size: 8
>>>>> Sending BC_REPLY
>>>>> Manager read_consumed: 8
>>>>> Manager command: BR_NOOP
>>>>> Manager command: BR_TRANSACTION_COMPLETE
>>>>> Client read_consumed: 72
>>>>> Client command: BR_NOOP
>>>>> Client command: BR_REPLY
>>>>> BR_REPLY data:
>>>>>   handle: 0
>>>>>   cookie: 0
>>>>>   code: 0
>>>>>   flag: TF_ACCEPT_FDS
>>>>>   sender pid: 0
>>>>>   sender euid: 0
>>>>>   data_size: 24
>>>>>   offsets_size: 8
>>>>> Retrieved Managers fd: 4 st_dev: 6
>>>>> Client read_consumed: 8
>>>>> Client using Managers FD command: BR_NOOP
>>>>> Client using Managers FD command: BR_FAILED_REPLY
>>>>> Client using Managers received FD failed response
>>>>> Manager read_consumed: 4
>>>>> Manager command: BR_NOOP
>>>>> not ok 1
>>>>> #   Failed test at ./test line 36.
>>>>
>>>> Just realized that I was testing with a kernel that still had
>>>> Casey's stacking support enabled.
>>>> Will re-try without that.
>>>
>>> Still fails for me on F28 with stock/linus 4.17.0-rc5.  No AVC
>>> messages from the failing test itself,
>>> just the other ones.
>>
>> Traced the client and saw that it was getting BR_FAILED_REPLY from
>> the kernel.
>> Looked at /sys/kernel/debug/binder/failed_transaction_log and saw
>> that the failure
>> occurs on line 2847.  Did a git blame on that line and found this
>> commit,
>>
>> commit 7aa135fcf26377f92dc0680a57566b4c7f3e281b
>> Author: Martijn Coenen <m...@android.com>
>> Date:   Wed Mar 28 11:14:50 2018 +0200
>>
>> ANDROID: binder: prevent transactions into own process.
>> 
>> This can't happen with normal nodes (because you can't get a ref
>> to a node you own), but it could happen with the context manager;
>> to make the behavior consistent with regular nodes, reject
>> transactions into the context manager by the process owning it.
>> 
>> Reported-by: syzbot+09e05aba06723a94d...@syzkaller.appspotmail.co
>> m
>> Signed-off-by: Martijn Coenen <m...@android.com>
>> Cc: stable <sta...@vger.kernel.org>
>> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>>
>> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
>> index 764b63a5aade..e578eee31589 100644
>> --- a/drivers/android/binder.c
>> +++ b/drivers/android/binder.c
>> @@ -2839,6 +2839,14 @@ static void binder_transaction(struct
>> binder_proc *proc,
>> else
>> return_error = BR_DEAD_REPLY;
>> mutex_unlock(
>>> context_mgr_node_lock);
>> +   if (target_node && target_proc == proc) {
>> +   binder_user_error("%d:%d got
>> transaction to context manager from process owning it\n",
>> + proc->pid, thread-
>>> pid);
>> +   return_error = BR_FAILED_REPLY;
>> +   return_error_param = -EINVAL;
>> +   return_error_line = __LINE__;
>> +   goto err_invalid_target_handle;
>> +   }
>> }
>> if (!target_node) {
>> /*
>>
>>
>> So that's a change in kernel behavior in v4.17-rc3 and later that
>> breaks your test code.
> 
> Thanks for the info. I'll get a new kernel and see how far I can get.

Simplest fix is to just not do the impersonation test, i.e. don't pass the
context manager's fd to the client at all.

Alternatively, you could introduce a third process ("server"), have it register
a binder with the context manager, have the client get a reference to it from
the context manager, have the client receive a ref to either the manager's or
the server's binder fd via binder, and have the client try to use that in a call
to the other one.  But that's a lot more complexity in your test.

Re: [RFC PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/15/2018 09:43 AM, Stephen Smalley wrote:
> On 05/15/2018 09:36 AM, Stephen Smalley wrote:
>> This test is failing for me (with or without -v):
>> # ./test -v
>> 1..6
>> Manager PID: 5608 Process context:
>>  unconfined_u:unconfined_r:test_binder_mgr_t:s0-s0:c0.c1023
>> Client PID: 5609 Process context:
>>  unconfined_u:unconfined_r:test_binder_client_t:s0-s0:c0.c1023
>> Client read_consumed: 28
>> Manager read_consumed: 72
>> Client command: BR_NOOP
>> Manager command: BR_NOOP
>> Client command: BR_INCREFS
>> Manager command: BR_TRANSACTION
>> Client command: BR_TRANSACTION_COMPLETE
>> BR_TRANSACTION data:
>>  handle: 0
>>  cookie: 0
>>  code: 0
>>  flag: TF_ACCEPT_FDS
>>  sender pid: 5609
>>  sender euid: 0
>>  data_size: 24
>>  offsets_size: 8
>> Sending BC_REPLY
>> Manager read_consumed: 8
>> Manager command: BR_NOOP
>> Manager command: BR_TRANSACTION_COMPLETE
>> Client read_consumed: 72
>> Client command: BR_NOOP
>> Client command: BR_REPLY
>> BR_REPLY data:
>>  handle: 0
>>  cookie: 0
>>  code: 0
>>  flag: TF_ACCEPT_FDS
>>  sender pid: 0
>>  sender euid: 0
>>  data_size: 24
>>  offsets_size: 8
>> Retrieved Managers fd: 4 st_dev: 6
>> Client read_consumed: 8
>> Client using Managers FD command: BR_NOOP
>> Client using Managers FD command: BR_FAILED_REPLY
>> Client using Managers received FD failed response
>> Manager read_consumed: 4
>> Manager command: BR_NOOP
>> not ok 1
>> #   Failed test at ./test line 36.
> 
> Just realized that I was testing with a kernel that still had Casey's 
> stacking support enabled.
> Will re-try without that.

Still fails for me on F28 with stock/linus 4.17.0-rc5.  No AVC messages from 
the failing test itself,
just the other ones.

Re: [RFC PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/15/2018 12:38 PM, Stephen Smalley wrote:
> On 05/15/2018 09:43 AM, Stephen Smalley wrote:
>> On 05/15/2018 09:36 AM, Stephen Smalley wrote:
>>> This test is failing for me (with or without -v):
>>> # ./test -v
>>> 1..6
>>> Manager PID: 5608 Process context:
>>> unconfined_u:unconfined_r:test_binder_mgr_t:s0-s0:c0.c1023
>>> Client PID: 5609 Process context:
>>> unconfined_u:unconfined_r:test_binder_client_t:s0-s0:c0.c1023
>>> Client read_consumed: 28
>>> Manager read_consumed: 72
>>> Client command: BR_NOOP
>>> Manager command: BR_NOOP
>>> Client command: BR_INCREFS
>>> Manager command: BR_TRANSACTION
>>> Client command: BR_TRANSACTION_COMPLETE
>>> BR_TRANSACTION data:
>>> handle: 0
>>> cookie: 0
>>> code: 0
>>> flag: TF_ACCEPT_FDS
>>> sender pid: 5609
>>> sender euid: 0
>>> data_size: 24
>>> offsets_size: 8
>>> Sending BC_REPLY
>>> Manager read_consumed: 8
>>> Manager command: BR_NOOP
>>> Manager command: BR_TRANSACTION_COMPLETE
>>> Client read_consumed: 72
>>> Client command: BR_NOOP
>>> Client command: BR_REPLY
>>> BR_REPLY data:
>>> handle: 0
>>> cookie: 0
>>> code: 0
>>> flag: TF_ACCEPT_FDS
>>> sender pid: 0
>>> sender euid: 0
>>> data_size: 24
>>> offsets_size: 8
>>> Retrieved Managers fd: 4 st_dev: 6
>>> Client read_consumed: 8
>>> Client using Managers FD command: BR_NOOP
>>> Client using Managers FD command: BR_FAILED_REPLY
>>> Client using Managers received FD failed response
>>> Manager read_consumed: 4
>>> Manager command: BR_NOOP
>>> not ok 1
>>> #   Failed test at ./test line 36.
>>
>> Just realized that I was testing with a kernel that still had Casey's 
>> stacking support enabled.
>> Will re-try without that.
> 
> Still fails for me on F28 with stock/linus 4.17.0-rc5.  No AVC messages from 
> the failing test itself,
> just the other ones.

Traced the client and saw that it was getting BR_FAILED_REPLY from the kernel.
Looked at /sys/kernel/debug/binder/failed_transaction_log and saw that the 
failure
occurs on line 2847.  Did a git blame on that line and found this commit,

commit 7aa135fcf26377f92dc0680a57566b4c7f3e281b
Author: Martijn Coenen <m...@android.com>
Date:   Wed Mar 28 11:14:50 2018 +0200

ANDROID: binder: prevent transactions into own process.

This can't happen with normal nodes (because you can't get a ref
to a node you own), but it could happen with the context manager;
to make the behavior consistent with regular nodes, reject
transactions into the context manager by the process owning it.

Reported-by: syzbot+09e05aba06723a94d...@syzkaller.appspotmail.com
Signed-off-by: Martijn Coenen <m...@android.com>
Cc: stable <sta...@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 764b63a5aade..e578eee31589 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2839,6 +2839,14 @@ static void binder_transaction(struct binder_proc *proc,
else
return_error = BR_DEAD_REPLY;
mutex_unlock(>context_mgr_node_lock);
+   if (target_node && target_proc == proc) {
+   binder_user_error("%d:%d got transaction to 
context manager from process owning it\n",
+ proc->pid, thread->pid);
+   return_error = BR_FAILED_REPLY;
+   return_error_param = -EINVAL;
+   return_error_line = __LINE__;
+   goto err_invalid_target_handle;
+   }
}
if (!target_node) {
/*


So that's a change in kernel behavior in v4.17-rc3 and later that breaks your 
test code.

Re: [PATCH] policycoreutils: fixfiles: failure to create /.autorelabel is fatal

[Stephen Smalley]

On 05/12/2018 08:43 AM, Alan Jenkins wrote:
> Fix the following ambiguous output (from booting with init=/bin/sh):
> 
> # /usr/sbin/fixfiles onboot
> /usr/sbin/fixfiles: line 313: /.autorelabel: Read-only file system
> /usr/sbin/fixfiles: line 317: /.autorelabel: Read-only file system
> System will relabel on next boot
> 
> System will not relabel on next boot if we couldn't create ./autorelabel
> 
> (In case anyone reading this description is still confused: To run
> `fixfiles onboot` after booting with init=/bin/sh, you must first run
> `mount / -oremount,rw`).

Thanks, applied.

> ---
>  policycoreutils/scripts/fixfiles | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/policycoreutils/scripts/fixfiles 
> b/policycoreutils/scripts/fixfiles
> index 0a46..69bd8488 100755
> --- a/policycoreutils/scripts/fixfiles
> +++ b/policycoreutils/scripts/fixfiles
> @@ -309,7 +309,7 @@ case "$1" in
>   usage
>   exit 1
>   fi
> - > /.autorelabel
> + > /.autorelabel || exit $?
>   [ -z "$FORCEFLAG" ] || echo -n "$FORCEFLAG " >> /.autorelabel
>   [ -z "$BOOTTIME" ] || echo -N $BOOTTIME >> /.autorelabel
>   # Force full relabel if / does not have a label on it
> 

Re: [RFC V3 PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/21/2018 01:02 PM, Stephen Smalley wrote:
> On 05/21/2018 12:33 PM, Richard Haines wrote:
>> Add binder tests. See tests/binder/test_binder.c for details on
>> message flows to test security_binder*() functions.
> 
> Breaks the build on RHEL7 since /usr/include/linux/android/binder.h does not 
> exist and is not
> provided by any package.  On F28 with v4.17-rc5, 2 tests fail at runtime:
> # ./test -v
> 1..6
> Manager PID: 5610 Process context:
>   unconfined_u:unconfined_r:test_binder_mgr_t:s0-s0:c0.c1023
> Service Provider PID: 5611 Process context:
>   unconfined_u:unconfined_r:test_binder_provider_t:s0-s0:c0.c1023
> Service Provider sending transaction to Manager - ADD_TEST_SERVICE
> Service Provider read_consumed: 8
> Service Provider command: BR_NOOP
> Service Provider command: BR_FAILED_REPLY
> not ok 1
> #   Failed test at ./test line 46.
> Service Provider PID: 5612 Process context:
>   unconfined_u:unconfined_r:test_binder_provider_no_call_t:s0-s0:c0.c1023
> Service Provider sending transaction to Manager - ADD_TEST_SERVICE
> Service Provider read_consumed: 8
> Service Provider command: BR_NOOP
> Service Provider command: BR_FAILED_REPLY
> ok 2
> Service Provider PID: 5613 Process context:
>   unconfined_u:unconfined_r:test_binder_provider_no_im_t:s0-s0:c0.c1023
> Service Provider sending transaction to Manager - ADD_TEST_SERVICE
> Service Provider read_consumed: 8
> Service Provider command: BR_NOOP
> Service Provider command: BR_FAILED_REPLY
> not ok 3
> #   Failed test at ./test line 56.
> Service Provider PID: 5614 Process context:
>   
> unconfined_u:unconfined_r:test_binder_provider_no_transfer_t:s0-s0:c0.c1023
> Service Provider sending transaction to Manager - ADD_TEST_SERVICE
> Service Provider read_consumed: 8
> Service Provider command: BR_NOOP
> Service Provider command: BR_FAILED_REPLY
> ok 4
> Manager PID: 5615 Process context:
>   unconfined_u:unconfined_r:test_binder_provider_t:s0-s0:c0.c1023
> Failed to become context manager: Permission denied
> ok 5
> Manager PID: 5616 Process context:
>   unconfined_u:unconfined_r:test_binder_mgr_no_fd_t:s0-s0:c0.c1023
> Service Provider PID: 5617 Process context:
>   unconfined_u:unconfined_r:test_binder_provider_t:s0-s0:c0.c1023
> Service Provider sending transaction to Manager - ADD_TEST_SERVICE
> Service Provider read_consumed: 8
> Service Provider command: BR_NOOP
> Service Provider command: BR_FAILED_REPLY
> ok 6
> # Looks like you failed 2 tests of 6.

dmesg output during the tests:
<6>[ 2769.139332] binder: 5827:5827 got transaction with invalid offset (4096, 
min 0 max 24) or object.
<6>[ 2769.139377] binder: 5827:5827 transaction failed 29201/-22, size 24-8 
line 3034
<6>[ 2769.159674] binder: 5828:5828 transaction failed 29201/-1, size 24-8 line 
2864
<6>[ 2769.170922] binder: 5829:5829 got transaction with invalid offset (4096, 
min 0 max 24) or object.
<6>[ 2769.170933] binder: 5829:5829 transaction failed 29201/-22, size 24-8 
line 3034
<6>[ 2769.182644] binder: 5830:5830 got transaction with invalid offset (4096, 
min 0 max 24) or object.
<6>[ 2769.182655] binder: 5830:5830 transaction failed 29201/-22, size 24-8 
line 3034
<6>[ 2769.199232] binder: 5831:5831 ioctl 40046207 0 returned -13
<6>[ 2769.209828] binder: 5832 RLIMIT_NICE not set
<6>[ 2769.495722] binder: 5833:5833 got transaction with invalid offset (4096, 
min 0 max 24) or object.
<6>[ 2769.495740] binder: 5833:5833 transaction failed 29201/-22, size 24-8 
line 3034

Re: [RFC V2 PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/20/2018 02:25 PM, Richard Haines wrote:
> Add binder tests. See tests/binder/test_binder.c for details on
> message flows to test security_binder*() functions.

Every test fails for me with:
create_shm shm_open: Permission denied
create_shm shm_open: No such file or directory

and denials of the form:
type=AVC msg=audit(1526902487.392:712): avc:  denied  { write } for  pid=3693 
comm="test_binder" name="/" dev="tmpfs" ino=14124 
scontext=unconfined_u:unconfined_r:test_binder_provider_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir permissive=0

> 
> Signed-off-by: Richard Haines 
> ---
>  README.md   |   8 +
>  defconfig   |   7 +
>  policy/Makefile |   4 +
>  policy/test_binder.te   |  96 +
>  tests/Makefile  |   4 +
>  tests/binder/Makefile   |   7 +
>  tests/binder/check_binder.c |  80 +
>  tests/binder/test   |  89 +
>  tests/binder/test_binder.c  | 685 
>  9 files changed, 980 insertions(+)
>  create mode 100644 policy/test_binder.te
>  create mode 100644 tests/binder/Makefile
>  create mode 100644 tests/binder/check_binder.c
>  create mode 100644 tests/binder/test
>  create mode 100644 tests/binder/test_binder.c
> 
> diff --git a/README.md b/README.md
> index c9f3b2b..60a249e 100644
> --- a/README.md
> +++ b/README.md
> @@ -141,6 +141,14 @@ directory or you can follow these broken-out steps:
>  The broken-out steps allow you to run the tests multiple times without
>  loading policy each time.
>  
> +Note that if leaving the test policy in-place for further testing, the
> +policy build process changes a boolean:
> +   On policy load:   setsebool allow_domain_fd_use=0
> +   On policy unload: setsebool allow_domain_fd_use=1
> +The consequence of this is that after a system reboot, the boolean
> +defaults to true. Therefore if running the fdreceive or binder tests,
> +reset the boolean to false, otherwise some tests will fail.
> +
>  4) Review the test results.
>  
>  As each test script is run, the name of the script will be displayed followed
> diff --git a/defconfig b/defconfig
> index 7dce8bc..c48d3cc 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -51,3 +51,10 @@ CONFIG_CRYPTO_USER=m
>  # This is enabled to test overlayfs SELinux integration.
>  # It is not required for SELinux operation itself.
>  CONFIG_OVERLAY_FS=m
> +
> +# Android binder implementations.
> +# These are enabled to test the binder controls in
> +# tests/binder; they are not required for SELinux operation itself.
> +CONFIG_ANDROID=y
> +CONFIG_ANDROID_BINDER_DEVICES="binder"
> +CONFIG_ANDROID_BINDER_IPC=y
> diff --git a/policy/Makefile b/policy/Makefile
> index 5e07ee2..15e3a0c 100644
> --- a/policy/Makefile
> +++ b/policy/Makefile
> @@ -63,6 +63,10 @@ ifeq ($(shell grep -q nnp_transition 
> $(POLDEV)/include/support/all_perms.spt &&
>  export M4PARAM += -Dnnp_nosuid_transition_permission_defined
>  endif
>  
> +ifeq ($(shell grep -q binder $(POLDEV)/include/support/all_perms.spt && echo 
> true),true)
> +TARGETS += test_binder.te
> +endif
> +
>  ifeq (x$(DISTRO),$(filter x$(DISTRO),xRHEL4 xRHEL5 xRHEL6))
>  TARGETS:=$(filter-out test_overlayfs.te test_mqueue.te, $(TARGETS))
>  endif
> diff --git a/policy/test_binder.te b/policy/test_binder.te
> new file mode 100644
> index 000..3fd4dd5
> --- /dev/null
> +++ b/policy/test_binder.te
> @@ -0,0 +1,96 @@
> +
> +attribute binderdomain;
> +
> +#
> +## Manager 
> ###
> +#
> +type test_binder_mgr_t;
> +domain_type(test_binder_mgr_t)
> +unconfined_runs_test(test_binder_mgr_t)
> +typeattribute test_binder_mgr_t testdomain;
> +typeattribute test_binder_mgr_t binderdomain;
> +allow test_binder_mgr_t self:binder { set_context_mgr call };
> +allow test_binder_mgr_t test_binder_provider_t:binder call;
> +allow test_binder_mgr_t device_t:chr_file { ioctl open read write map };
> +allow test_binder_mgr_t self:capability { sys_nice };
> +allow test_binder_provider_t test_binder_mgr_t:fd use;
> +fs_getattr_tmpfs(test_binder_mgr_t)
> +allow test_binder_mgr_t tmpfs_t:file { read write open map };
> +
> +#
> +## Manager no fd {use} 
> ###
> +#
> +type test_binder_mgr_no_fd_t;
> +domain_type(test_binder_mgr_no_fd_t)
> +unconfined_runs_test(test_binder_mgr_no_fd_t)
> +typeattribute test_binder_mgr_no_fd_t testdomain;
> +typeattribute test_binder_mgr_no_fd_t binderdomain;
> +allow test_binder_mgr_no_fd_t self:binder { set_context_mgr call };
> +allow test_binder_mgr_no_fd_t test_binder_provider_t:binder { call };
> +allow test_binder_mgr_no_fd_t device_t:chr_file { ioctl open read write map 
> };
> +allow test_binder_provider_t test_binder_mgr_no_fd_t:binder { call transfer 
> impersonate };
> +fs_getattr_tmpfs(test_binder_mgr_no_fd_t)
> +allow test_binder_mgr_no_fd_t tmpfs_t:file { read write open map };
> +
> +#

Re: [RFC V3 PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/21/2018 12:33 PM, Richard Haines wrote:
> Add binder tests. See tests/binder/test_binder.c for details on
> message flows to test security_binder*() functions.

Breaks the build on RHEL7 since /usr/include/linux/android/binder.h does not 
exist and is not
provided by any package.  On F28 with v4.17-rc5, 2 tests fail at runtime:
# ./test -v
1..6
Manager PID: 5610 Process context:
unconfined_u:unconfined_r:test_binder_mgr_t:s0-s0:c0.c1023
Service Provider PID: 5611 Process context:
unconfined_u:unconfined_r:test_binder_provider_t:s0-s0:c0.c1023
Service Provider sending transaction to Manager - ADD_TEST_SERVICE
Service Provider read_consumed: 8
Service Provider command: BR_NOOP
Service Provider command: BR_FAILED_REPLY
not ok 1
#   Failed test at ./test line 46.
Service Provider PID: 5612 Process context:
unconfined_u:unconfined_r:test_binder_provider_no_call_t:s0-s0:c0.c1023
Service Provider sending transaction to Manager - ADD_TEST_SERVICE
Service Provider read_consumed: 8
Service Provider command: BR_NOOP
Service Provider command: BR_FAILED_REPLY
ok 2
Service Provider PID: 5613 Process context:
unconfined_u:unconfined_r:test_binder_provider_no_im_t:s0-s0:c0.c1023
Service Provider sending transaction to Manager - ADD_TEST_SERVICE
Service Provider read_consumed: 8
Service Provider command: BR_NOOP
Service Provider command: BR_FAILED_REPLY
not ok 3
#   Failed test at ./test line 56.
Service Provider PID: 5614 Process context:

unconfined_u:unconfined_r:test_binder_provider_no_transfer_t:s0-s0:c0.c1023
Service Provider sending transaction to Manager - ADD_TEST_SERVICE
Service Provider read_consumed: 8
Service Provider command: BR_NOOP
Service Provider command: BR_FAILED_REPLY
ok 4
Manager PID: 5615 Process context:
unconfined_u:unconfined_r:test_binder_provider_t:s0-s0:c0.c1023
Failed to become context manager: Permission denied
ok 5
Manager PID: 5616 Process context:
unconfined_u:unconfined_r:test_binder_mgr_no_fd_t:s0-s0:c0.c1023
Service Provider PID: 5617 Process context:
unconfined_u:unconfined_r:test_binder_provider_t:s0-s0:c0.c1023
Service Provider sending transaction to Manager - ADD_TEST_SERVICE
Service Provider read_consumed: 8
Service Provider command: BR_NOOP
Service Provider command: BR_FAILED_REPLY
ok 6
# Looks like you failed 2 tests of 6.

> 
> Signed-off-by: Richard Haines 
> ---
>  README.md   |   8 +
>  defconfig   |   7 +
>  policy/Makefile |   4 +
>  policy/test_binder.te   | 120 +++
>  tests/Makefile  |   4 +
>  tests/binder/Makefile   |   7 +
>  tests/binder/check_binder.c |  80 +
>  tests/binder/test   |  89 +
>  tests/binder/test_binder.c  | 684 
>  9 files changed, 1003 insertions(+)
>  create mode 100644 policy/test_binder.te
>  create mode 100644 tests/binder/Makefile
>  create mode 100644 tests/binder/check_binder.c
>  create mode 100644 tests/binder/test
>  create mode 100644 tests/binder/test_binder.c
> 
> diff --git a/README.md b/README.md
> index c9f3b2b..60a249e 100644
> --- a/README.md
> +++ b/README.md
> @@ -141,6 +141,14 @@ directory or you can follow these broken-out steps:
>  The broken-out steps allow you to run the tests multiple times without
>  loading policy each time.
>  
> +Note that if leaving the test policy in-place for further testing, the
> +policy build process changes a boolean:
> +   On policy load:   setsebool allow_domain_fd_use=0
> +   On policy unload: setsebool allow_domain_fd_use=1
> +The consequence of this is that after a system reboot, the boolean
> +defaults to true. Therefore if running the fdreceive or binder tests,
> +reset the boolean to false, otherwise some tests will fail.
> +
>  4) Review the test results.
>  
>  As each test script is run, the name of the script will be displayed followed
> diff --git a/defconfig b/defconfig
> index 7dce8bc..c48d3cc 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -51,3 +51,10 @@ CONFIG_CRYPTO_USER=m
>  # This is enabled to test overlayfs SELinux integration.
>  # It is not required for SELinux operation itself.
>  CONFIG_OVERLAY_FS=m
> +
> +# Android binder implementations.
> +# These are enabled to test the binder controls in
> +# tests/binder; they are not required for SELinux operation itself.
> +CONFIG_ANDROID=y
> +CONFIG_ANDROID_BINDER_DEVICES="binder"
> +CONFIG_ANDROID_BINDER_IPC=y
> diff --git a/policy/Makefile b/policy/Makefile
> index 5e07ee2..15e3a0c 100644
> --- a/policy/Makefile
> +++ b/policy/Makefile
> @@ -63,6 +63,10 @@ ifeq ($(shell grep -q nnp_transition 
> $(POLDEV)/include/support/all_perms.spt &&
>  export M4PARAM += -Dnnp_nosuid_transition_permission_defined
>  endif
>  
> +ifeq ($(shell grep -q binder $(POLDEV)/include/support/all_perms.spt && echo 
> true),true)
> +TARGETS += test_binder.te
> +endif
> +
>  ifeq (x$(DISTRO),$(filter x$(DISTRO),xRHEL4 xRHEL5 

Re: [RFC V2 PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/20/2018 02:25 PM, Richard Haines wrote:
> Add binder tests. See tests/binder/test_binder.c for details on
> message flows to test security_binder*() functions.

Also, it breaks the policy build on RHEL/CentOS 7, due to map permission not 
being defined.
You need to use the allow_map() macro as we already do in many of the test 
policy files,
allow_map(domain, type, class).

> 
> Signed-off-by: Richard Haines 
> ---
>  README.md   |   8 +
>  defconfig   |   7 +
>  policy/Makefile |   4 +
>  policy/test_binder.te   |  96 +
>  tests/Makefile  |   4 +
>  tests/binder/Makefile   |   7 +
>  tests/binder/check_binder.c |  80 +
>  tests/binder/test   |  89 +
>  tests/binder/test_binder.c  | 685 
>  9 files changed, 980 insertions(+)
>  create mode 100644 policy/test_binder.te
>  create mode 100644 tests/binder/Makefile
>  create mode 100644 tests/binder/check_binder.c
>  create mode 100644 tests/binder/test
>  create mode 100644 tests/binder/test_binder.c
> 
> diff --git a/README.md b/README.md
> index c9f3b2b..60a249e 100644
> --- a/README.md
> +++ b/README.md
> @@ -141,6 +141,14 @@ directory or you can follow these broken-out steps:
>  The broken-out steps allow you to run the tests multiple times without
>  loading policy each time.
>  
> +Note that if leaving the test policy in-place for further testing, the
> +policy build process changes a boolean:
> +   On policy load:   setsebool allow_domain_fd_use=0
> +   On policy unload: setsebool allow_domain_fd_use=1
> +The consequence of this is that after a system reboot, the boolean
> +defaults to true. Therefore if running the fdreceive or binder tests,
> +reset the boolean to false, otherwise some tests will fail.
> +
>  4) Review the test results.
>  
>  As each test script is run, the name of the script will be displayed followed
> diff --git a/defconfig b/defconfig
> index 7dce8bc..c48d3cc 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -51,3 +51,10 @@ CONFIG_CRYPTO_USER=m
>  # This is enabled to test overlayfs SELinux integration.
>  # It is not required for SELinux operation itself.
>  CONFIG_OVERLAY_FS=m
> +
> +# Android binder implementations.
> +# These are enabled to test the binder controls in
> +# tests/binder; they are not required for SELinux operation itself.
> +CONFIG_ANDROID=y
> +CONFIG_ANDROID_BINDER_DEVICES="binder"
> +CONFIG_ANDROID_BINDER_IPC=y
> diff --git a/policy/Makefile b/policy/Makefile
> index 5e07ee2..15e3a0c 100644
> --- a/policy/Makefile
> +++ b/policy/Makefile
> @@ -63,6 +63,10 @@ ifeq ($(shell grep -q nnp_transition 
> $(POLDEV)/include/support/all_perms.spt &&
>  export M4PARAM += -Dnnp_nosuid_transition_permission_defined
>  endif
>  
> +ifeq ($(shell grep -q binder $(POLDEV)/include/support/all_perms.spt && echo 
> true),true)
> +TARGETS += test_binder.te
> +endif
> +
>  ifeq (x$(DISTRO),$(filter x$(DISTRO),xRHEL4 xRHEL5 xRHEL6))
>  TARGETS:=$(filter-out test_overlayfs.te test_mqueue.te, $(TARGETS))
>  endif
> diff --git a/policy/test_binder.te b/policy/test_binder.te
> new file mode 100644
> index 000..3fd4dd5
> --- /dev/null
> +++ b/policy/test_binder.te
> @@ -0,0 +1,96 @@
> +
> +attribute binderdomain;
> +
> +#
> +## Manager 
> ###
> +#
> +type test_binder_mgr_t;
> +domain_type(test_binder_mgr_t)
> +unconfined_runs_test(test_binder_mgr_t)
> +typeattribute test_binder_mgr_t testdomain;
> +typeattribute test_binder_mgr_t binderdomain;
> +allow test_binder_mgr_t self:binder { set_context_mgr call };
> +allow test_binder_mgr_t test_binder_provider_t:binder call;
> +allow test_binder_mgr_t device_t:chr_file { ioctl open read write map };
> +allow test_binder_mgr_t self:capability { sys_nice };
> +allow test_binder_provider_t test_binder_mgr_t:fd use;
> +fs_getattr_tmpfs(test_binder_mgr_t)
> +allow test_binder_mgr_t tmpfs_t:file { read write open map };
> +
> +#
> +## Manager no fd {use} 
> ###
> +#
> +type test_binder_mgr_no_fd_t;
> +domain_type(test_binder_mgr_no_fd_t)
> +unconfined_runs_test(test_binder_mgr_no_fd_t)
> +typeattribute test_binder_mgr_no_fd_t testdomain;
> +typeattribute test_binder_mgr_no_fd_t binderdomain;
> +allow test_binder_mgr_no_fd_t self:binder { set_context_mgr call };
> +allow test_binder_mgr_no_fd_t test_binder_provider_t:binder { call };
> +allow test_binder_mgr_no_fd_t device_t:chr_file { ioctl open read write map 
> };
> +allow test_binder_provider_t test_binder_mgr_no_fd_t:binder { call transfer 
> impersonate };
> +fs_getattr_tmpfs(test_binder_mgr_no_fd_t)
> +allow test_binder_mgr_no_fd_t tmpfs_t:file { read write open map };
> +
> +#
> +## Service Provider 
> +#
> +type test_binder_provider_t;
> +domain_type(test_binder_provider_t)
> 

Re: [RFC V4 PATCH 1/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/22/2018 07:37 AM, Richard Haines wrote:
> Add binder tests. See tests/binder/test_binder.c for details on
> message flows to test security_binder*() functions.
> 
> Signed-off-by: Richard Haines <richard_c_hai...@btinternet.com>

Passes for me with 4.17-rc5 on F28 and properly skipped on earlier Fedora/RHEL.

Acked-by: Stephen Smalley <s...@tycho.nsa.gov>

> ---
>  README.md   |   8 +
>  defconfig   |   7 +
>  policy/Makefile |   4 +
>  policy/test_binder.te   | 120 +++
>  tests/Makefile  |   5 +
>  tests/binder/Makefile   |   7 +
>  tests/binder/check_binder.c |  80 +
>  tests/binder/test   |  89 +
>  tests/binder/test_binder.c  | 684 
>  9 files changed, 1004 insertions(+)
>  create mode 100644 policy/test_binder.te
>  create mode 100644 tests/binder/Makefile
>  create mode 100644 tests/binder/check_binder.c
>  create mode 100644 tests/binder/test
>  create mode 100644 tests/binder/test_binder.c
> 
> diff --git a/README.md b/README.md
> index c9f3b2b..60a249e 100644
> --- a/README.md
> +++ b/README.md
> @@ -141,6 +141,14 @@ directory or you can follow these broken-out steps:
>  The broken-out steps allow you to run the tests multiple times without
>  loading policy each time.
>  
> +Note that if leaving the test policy in-place for further testing, the
> +policy build process changes a boolean:
> +   On policy load:   setsebool allow_domain_fd_use=0
> +   On policy unload: setsebool allow_domain_fd_use=1
> +The consequence of this is that after a system reboot, the boolean
> +defaults to true. Therefore if running the fdreceive or binder tests,
> +reset the boolean to false, otherwise some tests will fail.
> +
>  4) Review the test results.
>  
>  As each test script is run, the name of the script will be displayed followed
> diff --git a/defconfig b/defconfig
> index 7dce8bc..c48d3cc 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -51,3 +51,10 @@ CONFIG_CRYPTO_USER=m
>  # This is enabled to test overlayfs SELinux integration.
>  # It is not required for SELinux operation itself.
>  CONFIG_OVERLAY_FS=m
> +
> +# Android binder implementations.
> +# These are enabled to test the binder controls in
> +# tests/binder; they are not required for SELinux operation itself.
> +CONFIG_ANDROID=y
> +CONFIG_ANDROID_BINDER_DEVICES="binder"
> +CONFIG_ANDROID_BINDER_IPC=y
> diff --git a/policy/Makefile b/policy/Makefile
> index 5e07ee2..15e3a0c 100644
> --- a/policy/Makefile
> +++ b/policy/Makefile
> @@ -63,6 +63,10 @@ ifeq ($(shell grep -q nnp_transition 
> $(POLDEV)/include/support/all_perms.spt &&
>  export M4PARAM += -Dnnp_nosuid_transition_permission_defined
>  endif
>  
> +ifeq ($(shell grep -q binder $(POLDEV)/include/support/all_perms.spt && echo 
> true),true)
> +TARGETS += test_binder.te
> +endif
> +
>  ifeq (x$(DISTRO),$(filter x$(DISTRO),xRHEL4 xRHEL5 xRHEL6))
>  TARGETS:=$(filter-out test_overlayfs.te test_mqueue.te, $(TARGETS))
>  endif
> diff --git a/policy/test_binder.te b/policy/test_binder.te
> new file mode 100644
> index 000..0589396
> --- /dev/null
> +++ b/policy/test_binder.te
> @@ -0,0 +1,120 @@
> +
> +attribute binderdomain;
> +
> +#
> +## Manager 
> ###
> +#
> +type test_binder_mgr_t;
> +domain_type(test_binder_mgr_t)
> +unconfined_runs_test(test_binder_mgr_t)
> +typeattribute test_binder_mgr_t testdomain;
> +typeattribute test_binder_mgr_t binderdomain;
> +allow test_binder_mgr_t self:binder { set_context_mgr call };
> +allow test_binder_mgr_t test_binder_provider_t:binder call;
> +allow test_binder_mgr_t device_t:chr_file { ioctl open read write };
> +allow_map(test_binder_mgr_t, device_t, chr_file)
> +allow test_binder_mgr_t self:capability { sys_nice };
> +allow test_binder_provider_t test_binder_mgr_t:fd use;
> +fs_getattr_tmpfs(test_binder_mgr_t)
> +allow test_binder_mgr_t tmpfs_t:file { read write open };
> +allow_map(test_binder_mgr_t, tmpfs_t, file)
> +fs_manage_tmpfs_dirs(test_binder_mgr_t)
> +fs_manage_tmpfs_files(test_binder_mgr_t)
> +
> +#
> +## Manager no fd {use} 
> ###
> +#
> +type test_binder_mgr_no_fd_t;
> +domain_type(test_binder_mgr_no_fd_t)
> +unconfined_runs_test(test_binder_mgr_no_fd_t)
> +typeattribute test_binder_mgr_no_fd_t testdomain;
> +typeattribute test_binder_mgr_no_fd_t binderdomain;
> +allow test_binder_mgr_no_fd_t self:binder { set_context_mgr call };
> +allow test_binder_mgr_no_fd_t test_binder_provider_t:binder { call };
> +allow test_bi

Re: [RFC V4 PATCH 0/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/22/2018 09:53 AM, Stephen Smalley wrote:
> On 05/22/2018 09:11 AM, Stephen Smalley wrote:
>> On 05/22/2018 09:01 AM, Stephen Smalley wrote:
>>> On 05/22/2018 07:37 AM, Richard Haines wrote:
>>>> Could you try this version where I've packed the transaction structures.
>>>> I could not get the tests to fail on my two systems (but then V3 didn't).
>>>
>>> Hmmm...I saw one instance of a failure in test 6 when running ./test by
>>> hand but am now having problems replicating it.
>>>
>>> dmesg output during all 6 tests was:
>>>
>>> [  263.831513] binder: release 2025:2025 transaction 2 out, still active
>>> [  263.831519] binder: 2024:2024 transaction failed 29189/0, size 24-8 line 
>>> 2788
>>> [  263.831522] binder: send failed reply for transaction 2, target dead
>>> [  263.846321] binder: 2026:2026 transaction failed 29201/-1, size 24-8 
>>> line 2864
>>> [  263.858613] binder: 2024:2027 transaction failed 29201/-1, size 0-0 line 
>>> 2864
>>> [  263.872764] binder: 2028:2028 transaction failed 29201/-1, size 24-8 
>>> line 3050
>>> [  263.883684] binder: 2029:2029 ioctl 40046207 0 returned -13
>>> [  263.895261] binder: 2030 RLIMIT_NICE not set
>>> [  264.151699] binder: 2030 RLIMIT_NICE not set
>>> [  264.151879] binder: 2030 RLIMIT_NICE not set
>>> [  264.152212] binder: undelivered transaction 19, process died.
>>> [  264.152219] binder: 2030 RLIMIT_NICE not set
>>> [  264.153438] binder: 2030 RLIMIT_NICE not set
>>>
>>> Are all of those expected?
>>
>> Now it is repeating upon a fresh reboot and running ./test by hand 
>> repeatedly.
>> Also seeing these errors:
>> [  176.467915] binder_alloc: 1998: binder_alloc_buf, no vma
>> [  176.468046] binder: undelivered TRANSACTION_ERROR: 29189
>>
>> Running it via make test passes though, oddly enough.
>>
>> This is with completely stock 4.17-rc5 on F28.
> 
> ./test -v reports the following for test 6:
> Manager PID: 1949 Process context:
>   unconfined_u:unconfined_r:test_binder_mgr_no_fd_t:s0-s0:c0.c1023
> Service Provider PID: 1950 Process context:
>   unconfined_u:unconfined_r:test_binder_provider_t:s0-s0:c0.c1023
> Service Provider sending transaction to Manager - ADD_TEST_SERVICE
> Service Provider read_consumed: 48
> Service Provider command: BR_NOOP
> Service Provider command: BR_INCREFS
> Service Provider command: BR_ACQUIRE
> Service Provider command: BR_TRANSACTION_COMPLETE
> Manager read_consumed: 72
> Manager command: BR_NOOP
> Manager command: BR_TRANSACTION
> Manager BR_TRANSACTION data:
>   handle: 0
>   cookie: 0
>   code: 100
>   flag: TF_ACCEPT_FDS
>   sender pid: 1950
>   sender euid: 0
>   data_size: 24
>   offsets_size: 8
>   hdr: BINDER_TYPE_HANDLE
>   handle: 1
>   flags: priority: 0x7f accept FDS: YES
>   cookie: 0
> Manager has BINDER_TYPE_HANDLE obj->handle: 1
> Manager acquired handle: 1 for Service Provider
> Manager sending BC_REPLY to obtain its FD
> Manager handle: 0 and its FD: 3
> Manager read_consumed: 8
> Manager command: BR_NOOP
> Manager command: BR_TRANSACTION_COMPLETE
> Service Provider read_consumed: 72
> Service Provider command: BR_NOOP
> Service Provider command: BR_REPLY
> Service Provider BR_REPLY data:
>   handle: 0
>   cookie: 0
>   code: 100
>   flag: TF_ACCEPT_FDS
>   sender pid: 0
>   sender euid: 0
>   data_size: 24
>   offsets_size: 8
>   hdr: BINDER_TYPE_FD
>   fd: 5
>   flags: priority: 0x7f accept FDS: YES
>   cookie: 0
> Service Provider retrieved Managers fd: 5 st_dev: 6
> Service Provider read_consumed: 8
> Service Provider command: BR_NOOP
> Service Provider command: BR_TRANSACTION_COMPLETE
> Service Provider using Managers FD
> Manager read_consumed: 4
> Manager command: BR_NOOP
> not ok 6
> #   Failed test at ./test line 84.
> # Looks like you failed 1 test of 6.

Never mind, bug in user, forgot to setsebool domain_fd_use=off before running 
after a reboot (or
re-running make -C policy load).

Test passes for me now.

Re: [RFC V4 PATCH 0/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/22/2018 09:01 AM, Stephen Smalley wrote:
> On 05/22/2018 07:37 AM, Richard Haines wrote:
>> Could you try this version where I've packed the transaction structures.
>> I could not get the tests to fail on my two systems (but then V3 didn't).
> 
> Hmmm...I saw one instance of a failure in test 6 when running ./test by
> hand but am now having problems replicating it.
> 
> dmesg output during all 6 tests was:
> 
> [  263.831513] binder: release 2025:2025 transaction 2 out, still active
> [  263.831519] binder: 2024:2024 transaction failed 29189/0, size 24-8 line 
> 2788
> [  263.831522] binder: send failed reply for transaction 2, target dead
> [  263.846321] binder: 2026:2026 transaction failed 29201/-1, size 24-8 line 
> 2864
> [  263.858613] binder: 2024:2027 transaction failed 29201/-1, size 0-0 line 
> 2864
> [  263.872764] binder: 2028:2028 transaction failed 29201/-1, size 24-8 line 
> 3050
> [  263.883684] binder: 2029:2029 ioctl 40046207 0 returned -13
> [  263.895261] binder: 2030 RLIMIT_NICE not set
> [  264.151699] binder: 2030 RLIMIT_NICE not set
> [  264.151879] binder: 2030 RLIMIT_NICE not set
> [  264.152212] binder: undelivered transaction 19, process died.
> [  264.152219] binder: 2030 RLIMIT_NICE not set
> [  264.153438] binder: 2030 RLIMIT_NICE not set
> 
> Are all of those expected?

Now it is repeating upon a fresh reboot and running ./test by hand repeatedly.
Also seeing these errors:
[  176.467915] binder_alloc: 1998: binder_alloc_buf, no vma
[  176.468046] binder: undelivered TRANSACTION_ERROR: 29189

Running it via make test passes though, oddly enough.

This is with completely stock 4.17-rc5 on F28.

> 
> /sys/kernel/debug/binder/failed_transaction_log contained:
> 
> 5: reply from 2024:2024 to 0:0 context binder node 0 handle 0 size 24:8 ret 
> 29189/0 l=2788
> 6: call  from 2026:2026 to 0:0 context binder node 1 handle 0 size 24:8 ret 
> 29201/-1 l=2864
> 11: async from 2024:2027 to 0:0 context binder node 8 handle 2 size 0:0 ret 
> 29201/-1 l=2864
> 12: call  from 2028:2028 to 2024:0 context binder node 1 handle 0 size 24:8 
> ret 29201/-1 l=3050
> 24: reply from 2039:2039 to 2040:2040 context binder node 0 handle 0 size 
> 24:8 ret 29189/-3 l=2971
> 25: call  from 2041:2041 to 0:0 context binder node 20 handle 0 size 24:8 ret 
> 29201/-1 l=2864
> 30: async from 2039:2042 to 0:0 context binder node 27 handle 2 size 0:0 ret 
> 29201/-1 l=2864
> 31: call  from 2043:2043 to 2039:0 context binder node 20 handle 0 size 24:8 
> ret 29201/-1 l=3050
> 43: reply from 2050:2050 to 2051:2051 context binder node 0 handle 0 size 
> 24:8 ret 29189/-3 l=2971
> 44: call  from 2052:2052 to 0:0 context binder node 39 handle 0 size 24:8 ret 
> 29201/-1 l=2864
> 49: async from 2050:2053 to 0:0 context binder node 46 handle 2 size 0:0 ret 
> 29201/-1 l=2864
> 50: call  from 2054:2054 to 2050:0 context binder node 39 handle 0 size 24:8 
> ret 29201/-1 l=3050
> 62: reply from 2062:2062 to 0:0 context binder node 0 handle 0 size 24:8 ret 
> 29189/0 l=2788
> 63: call  from 2064:2064 to 0:0 context binder node 58 handle 0 size 24:8 ret 
> 29201/-1 l=2864
> 68: async from 2062:2065 to 0:0 context binder node 65 handle 2 size 0:0 ret 
> 29201/-1 l=2864
> 69: call  from 2066:2066 to 2062:0 context binder node 58 handle 0 size 24:8 
> ret 29201/-1 l=3050
> 
>>
>> Thanks
>>
>> I've updated this so it still tests all the binder permissions.
>>
>> I didn't bother with a Client as I found another way to achieve the
>> same result. Plenty of comments in test_binder.c to explain. Hopefully
>> it is sane, otherwise a Client will be required.
>>
>> I've tested on Fedora 28 with linux-4.17-rc5 so that it does not
>> suffer the same fate as V1 did. Also looked to see what other patches
>> were in the pipeline, none that should stop this version working.
>>
>> V2 Changes:
>> Fixed the policy and test Makefiles
>> Updated binder policy.
>> Updated the defconfig and now works to build linux-4.17-rc5
>> Updated the test to handle the -v option. Plenty of output
>> to see what is happening.
>>
>> V3 Changes:
>> Added missing policy for using shared memory.
>> Use the allow_map macro.
>>
>> V4 Changes:
>> Pack transaction structures.
>> Check if $(INCLUDEDIR)/linux/android/binder.h exists.
>>
>> Richard Haines (1):
>>   selinux-testsuite: Add binder tests
>>
>>  README.md   |   8 +
>>  defconfig   |   7 +
>>  policy/Makefile |   4 +
>>  policy/test_binder.te   | 120 +++
>>  tests/Makefile  |   5 +
>>  tests/binder/Makefile   |   7 +

Re: [RFC V4 PATCH 0/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/22/2018 09:11 AM, Stephen Smalley wrote:
> On 05/22/2018 09:01 AM, Stephen Smalley wrote:
>> On 05/22/2018 07:37 AM, Richard Haines wrote:
>>> Could you try this version where I've packed the transaction structures.
>>> I could not get the tests to fail on my two systems (but then V3 didn't).
>>
>> Hmmm...I saw one instance of a failure in test 6 when running ./test by
>> hand but am now having problems replicating it.
>>
>> dmesg output during all 6 tests was:
>>
>> [  263.831513] binder: release 2025:2025 transaction 2 out, still active
>> [  263.831519] binder: 2024:2024 transaction failed 29189/0, size 24-8 line 
>> 2788
>> [  263.831522] binder: send failed reply for transaction 2, target dead
>> [  263.846321] binder: 2026:2026 transaction failed 29201/-1, size 24-8 line 
>> 2864
>> [  263.858613] binder: 2024:2027 transaction failed 29201/-1, size 0-0 line 
>> 2864
>> [  263.872764] binder: 2028:2028 transaction failed 29201/-1, size 24-8 line 
>> 3050
>> [  263.883684] binder: 2029:2029 ioctl 40046207 0 returned -13
>> [  263.895261] binder: 2030 RLIMIT_NICE not set
>> [  264.151699] binder: 2030 RLIMIT_NICE not set
>> [  264.151879] binder: 2030 RLIMIT_NICE not set
>> [  264.152212] binder: undelivered transaction 19, process died.
>> [  264.152219] binder: 2030 RLIMIT_NICE not set
>> [  264.153438] binder: 2030 RLIMIT_NICE not set
>>
>> Are all of those expected?
> 
> Now it is repeating upon a fresh reboot and running ./test by hand repeatedly.
> Also seeing these errors:
> [  176.467915] binder_alloc: 1998: binder_alloc_buf, no vma
> [  176.468046] binder: undelivered TRANSACTION_ERROR: 29189
> 
> Running it via make test passes though, oddly enough.
> 
> This is with completely stock 4.17-rc5 on F28.

./test -v reports the following for test 6:
Manager PID: 1949 Process context:
unconfined_u:unconfined_r:test_binder_mgr_no_fd_t:s0-s0:c0.c1023
Service Provider PID: 1950 Process context:
unconfined_u:unconfined_r:test_binder_provider_t:s0-s0:c0.c1023
Service Provider sending transaction to Manager - ADD_TEST_SERVICE
Service Provider read_consumed: 48
Service Provider command: BR_NOOP
Service Provider command: BR_INCREFS
Service Provider command: BR_ACQUIRE
Service Provider command: BR_TRANSACTION_COMPLETE
Manager read_consumed: 72
Manager command: BR_NOOP
Manager command: BR_TRANSACTION
Manager BR_TRANSACTION data:
handle: 0
cookie: 0
code: 100
flag: TF_ACCEPT_FDS
sender pid: 1950
sender euid: 0
data_size: 24
offsets_size: 8
hdr: BINDER_TYPE_HANDLE
handle: 1
flags: priority: 0x7f accept FDS: YES
cookie: 0
Manager has BINDER_TYPE_HANDLE obj->handle: 1
Manager acquired handle: 1 for Service Provider
Manager sending BC_REPLY to obtain its FD
Manager handle: 0 and its FD: 3
Manager read_consumed: 8
Manager command: BR_NOOP
Manager command: BR_TRANSACTION_COMPLETE
Service Provider read_consumed: 72
Service Provider command: BR_NOOP
Service Provider command: BR_REPLY
Service Provider BR_REPLY data:
handle: 0
cookie: 0
code: 100
flag: TF_ACCEPT_FDS
sender pid: 0
sender euid: 0
data_size: 24
offsets_size: 8
hdr: BINDER_TYPE_FD
fd: 5
flags: priority: 0x7f accept FDS: YES
cookie: 0
Service Provider retrieved Managers fd: 5 st_dev: 6
Service Provider read_consumed: 8
Service Provider command: BR_NOOP
Service Provider command: BR_TRANSACTION_COMPLETE
Service Provider using Managers FD
Manager read_consumed: 4
Manager command: BR_NOOP
not ok 6
#   Failed test at ./test line 84.
# Looks like you failed 1 test of 6.

Re: [RFC V4 PATCH 0/1] selinux-testsuite: Add binder tests

[Stephen Smalley]

On 05/22/2018 07:37 AM, Richard Haines wrote:
> Could you try this version where I've packed the transaction structures.
> I could not get the tests to fail on my two systems (but then V3 didn't).

Hmmm...I saw one instance of a failure in test 6 when running ./test by
hand but am now having problems replicating it.

dmesg output during all 6 tests was:

[  263.831513] binder: release 2025:2025 transaction 2 out, still active
[  263.831519] binder: 2024:2024 transaction failed 29189/0, size 24-8 line 2788
[  263.831522] binder: send failed reply for transaction 2, target dead
[  263.846321] binder: 2026:2026 transaction failed 29201/-1, size 24-8 line 
2864
[  263.858613] binder: 2024:2027 transaction failed 29201/-1, size 0-0 line 2864
[  263.872764] binder: 2028:2028 transaction failed 29201/-1, size 24-8 line 
3050
[  263.883684] binder: 2029:2029 ioctl 40046207 0 returned -13
[  263.895261] binder: 2030 RLIMIT_NICE not set
[  264.151699] binder: 2030 RLIMIT_NICE not set
[  264.151879] binder: 2030 RLIMIT_NICE not set
[  264.152212] binder: undelivered transaction 19, process died.
[  264.152219] binder: 2030 RLIMIT_NICE not set
[  264.153438] binder: 2030 RLIMIT_NICE not set

Are all of those expected?

/sys/kernel/debug/binder/failed_transaction_log contained:

5: reply from 2024:2024 to 0:0 context binder node 0 handle 0 size 24:8 ret 
29189/0 l=2788
6: call  from 2026:2026 to 0:0 context binder node 1 handle 0 size 24:8 ret 
29201/-1 l=2864
11: async from 2024:2027 to 0:0 context binder node 8 handle 2 size 0:0 ret 
29201/-1 l=2864
12: call  from 2028:2028 to 2024:0 context binder node 1 handle 0 size 24:8 ret 
29201/-1 l=3050
24: reply from 2039:2039 to 2040:2040 context binder node 0 handle 0 size 24:8 
ret 29189/-3 l=2971
25: call  from 2041:2041 to 0:0 context binder node 20 handle 0 size 24:8 ret 
29201/-1 l=2864
30: async from 2039:2042 to 0:0 context binder node 27 handle 2 size 0:0 ret 
29201/-1 l=2864
31: call  from 2043:2043 to 2039:0 context binder node 20 handle 0 size 24:8 
ret 29201/-1 l=3050
43: reply from 2050:2050 to 2051:2051 context binder node 0 handle 0 size 24:8 
ret 29189/-3 l=2971
44: call  from 2052:2052 to 0:0 context binder node 39 handle 0 size 24:8 ret 
29201/-1 l=2864
49: async from 2050:2053 to 0:0 context binder node 46 handle 2 size 0:0 ret 
29201/-1 l=2864
50: call  from 2054:2054 to 2050:0 context binder node 39 handle 0 size 24:8 
ret 29201/-1 l=3050
62: reply from 2062:2062 to 0:0 context binder node 0 handle 0 size 24:8 ret 
29189/0 l=2788
63: call  from 2064:2064 to 0:0 context binder node 58 handle 0 size 24:8 ret 
29201/-1 l=2864
68: async from 2062:2065 to 0:0 context binder node 65 handle 2 size 0:0 ret 
29201/-1 l=2864
69: call  from 2066:2066 to 2062:0 context binder node 58 handle 0 size 24:8 
ret 29201/-1 l=3050

> 
> Thanks
> 
> I've updated this so it still tests all the binder permissions.
> 
> I didn't bother with a Client as I found another way to achieve the
> same result. Plenty of comments in test_binder.c to explain. Hopefully
> it is sane, otherwise a Client will be required.
> 
> I've tested on Fedora 28 with linux-4.17-rc5 so that it does not
> suffer the same fate as V1 did. Also looked to see what other patches
> were in the pipeline, none that should stop this version working.
> 
> V2 Changes:
> Fixed the policy and test Makefiles
> Updated binder policy.
> Updated the defconfig and now works to build linux-4.17-rc5
> Updated the test to handle the -v option. Plenty of output
> to see what is happening.
> 
> V3 Changes:
> Added missing policy for using shared memory.
> Use the allow_map macro.
> 
> V4 Changes:
> Pack transaction structures.
> Check if $(INCLUDEDIR)/linux/android/binder.h exists.
> 
> Richard Haines (1):
>   selinux-testsuite: Add binder tests
> 
>  README.md   |   8 +
>  defconfig   |   7 +
>  policy/Makefile |   4 +
>  policy/test_binder.te   | 120 +++
>  tests/Makefile  |   5 +
>  tests/binder/Makefile   |   7 +
>  tests/binder/check_binder.c |  80 +
>  tests/binder/test   |  89 +
>  tests/binder/test_binder.c  | 684 
>  9 files changed, 1004 insertions(+)
>  create mode 100644 policy/test_binder.te
>  create mode 100644 tests/binder/Makefile
>  create mode 100644 tests/binder/check_binder.c
>  create mode 100644 tests/binder/test
>  create mode 100644 tests/binder/test_binder.c
> 

Re: Selinux load_policy command on chrooted partition is loading policy on active partition

[Stephen Smalley]

On 05/25/2018 04:08 AM, bhawna goel wrote:
> Hi Team,
> 
> We are facing an issue with load_policy command on Centos 7.4.. Need to 
> understand what it exactly does.
> 
> We have Centos 7.4 machine which have two partitions .
> Ist partition (partA) have all the policies with unconfined and when we are 
> installing second partition (partB) we are adding all the policies for 
> sysadm. 
> During installation of partB below command is getting executed from partA
> chroot partB load_policy -qi.
> 
> Just after executing this command partA stops working with unconfined 
> policies . partA giving denials which was working before executing this 
> command.
> 
> Just to recover my system i executed load_policy -q in partA and it gets back 
> to normal.
> 
> I wanted to understand what exactly load_policy do . Why my partA stopped 
> working when load_policy is executed in partB .Is this expected behavior or 
> there is some issue.
> 
> Thanks in advance.

I thought I answered this yesterday, but let's try again: load_policy always 
loads the active policy as defined by /etc/selinux/config relative to its root. 
So if you perform a chroot /path/to/partB load_policy it will load the policy 
from /path/to/partB/etc/selinux into the kernel.  And then your partA will stop 
working.  There is only one kernel policy; it isn't relative to any particular 
root.  Don't load policy from partB unless you are actually booting from partB.
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Selinux load_policy command on inactive partition is loading policy on active partition

[Stephen Smalley]

On 05/24/2018 01:48 AM, shagun maheshwari wrote:
> Hi,
> 
> We have done changes in our Centos7.4 to disable the unconfined user from our 
> code. We have created an iso in which we have replaced unconfined with sysadm 
> and we are performing an upgrade using the new iso. 
> After upgrade current partition stop working. It started expecting policies 
> for unconfined when we perform reboot things started working fine again. 
> We are suspecting some issues with this command "load_policy -qi" when this 
> command is being executed on partB in permissive mode and after we move the 
> system to enforcing mode. It starts giving denials for unconfined. 
> 
> Can you explain what exactly load_policy do? 
> Does it load the policies for all the partitions of the system?

load_policy always loads the active system policy as defined by 
/etc/selinux/config.  If you want it to load a policy from another partition 
you need to run it under chroot or a filesystem namespace such that it uses 
/etc/selinux from the other partition.  It only loads one policy though, not 
multiple.

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

ANN: SELinux userspace release 20180524 / 2.8

[Stephen Smalley]

The 20180524 / 2.8 release for the SELinux userspace is now available at:
https://github.com/SELinuxProject/selinux/wiki/Releases

A github release has also been created at:
https://github.com/SELinuxProject/selinux/releases/tag/20180524

In the future, we will likely stop hosting the releases on the wiki and
just have it link to the github releases.  We may also alter the versioning
and tagging scheme. For this release however, I have left these unchanged.

Below are some notes on this release for packagers and users of the
SELinux userspace.  git log and git shortlog output for all changes
since the 20170804 / 2.7 release are available from the release page. 

Thanks to all the contributors to this release!

RELEASE 20180524 (2.8)

User-visible changes:

* semanage fcontext -l now also lists home directory entries from
file_contexts.homedirs.

* semodule can now enable or disable multiple modules in the same
operation by specifying a list of modules after -e or -d, making them
consistent with the -i/u/r/E options.

* CIL now supports multiple declarations of types, attributes, and
(non-conflicting) object contexts (e.g. genfscon), enabled via the -m
or --multiple-decls option to secilc.

* libsemanage no longer deletes the tmp directory if there is an error
while committing the policy transaction, so that any temporary files
can be further inspected for debugging purposes (e.g. to examine a
particular line of the generated CIL module).  The tmp directory will
be deleted upon the next transaction, so no manual removal is needed.

* Support was added for SCTP portcon statements. The corresponding
kernel support was introduced in Linux 4.17, and is only active if the
extended_socket_class policy capability is enabled in the policy.  This
support is required to build the refpolicy master branch (and thus future
refpolicy releases).

* sepol_polcap_getnum/name() were exported as part of the shared libsepol
interface, initially for use by setools4.

* semodule_deps was removed since it has long been broken and is not useful
for CIL modules.

Packaging-relevant changes:

* When overriding PREFIX, BINDIR, SBINDIR, SHLIBDIR, LIBEXECDIR, etc.,
DESTDIR has to be removed from the definition. For example on Arch
Linux, SBINDIR="${pkgdir}/usr/bin" was changed to SBINDIR="/usr/bin".

* Defining variable LIBSEPOLA (to /usr/lib/libsepol.a, for example) is
no longer mandatory (thanks to the switch to "-l:libsepol.a" in
Makefiles).

* PYSITEDIR has been renamed PYTHONLIBDIR (and its definition changed).

* selinux-gui (i.e. system-config-selinux GUI application) is now
compatible with Python 3. Doing this required migrating away from
PyGTK to the supported PyGI library. This means that selinux-gui now
depends on python-gobject, Gtk+ 3 and selinux-python. It no longer
requires PyGtk or Python 2.
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [Bug][KASAN] crash in xattr_getsecurity()

[Stephen Smalley]

On 05/24/2018 02:12 AM, Sachin Grover wrote:
> Hi,
> 
> Kernel panic is coming on calling lgetxattr() sys api with random user space 
> value.
> 
> [   25.833951] Call trace:
> [   25.833954] [] dump_backtrace+0x0/0x2a8
> [   25.833957] [] show_stack+0x20/0x28
> [   25.833959] [] dump_stack+0xa8/0xe0
> [   25.833962] [] xattr_getsecurity+0xac/0xd4
> [   25.833964] [] vfs_getxattr+0x98/0xcc
> [   25.833966] [] getxattr+0x9c/0x1d4
> [   25.833969] [] path_getxattr+0x74/0xc4
> [   25.833971] [] SyS_lgetxattr+0x3c/0x48
> [   25.833973] [] el0_svc_naked+0x24/0x28
> 
> setxattr() is getting size and value from the userspace, if I am giving size 
> as 64840, my code is entering this part and crashing on doing memcpy under  
> xattr_getsecurity().
> 
> rc  = 
> string_to_context_struct(, , scontext2,
> scontext_len 
> ,
>   
> , 
> def_sid 
> );
>   *if* (rc 
>  == 
> -EINVAL 
>  && 
> force 
> ) {
>   context 
> .str
>  = str;
>   context 
> .len
>   = 
> scontext_len 
> ;
>   str = NULL 
> ;
> 
> 
> 
> //rc value is coming as EINVAL(-22). In pass case rc value is always 0.
> 
> 
> Please let me know if this fix is good enough.
> 
> 
> rc  = 
> string_to_context_struct(, , scontext2,
> scontext_len 
> ,
>   
> , 
> def_sid 
> );
>   *if* (rc 
>  == 
> -EINVAL 
>  && 
> force 
> ) {
>   context 
> .str
>  = str;
> -  context 
> .len
>   = 
> scontext_len 
> ;
> 
> +  context.len = strlen(str);
> 
>   str = NULL 
> ;

IIUC, this is only possible if a process with CAP_MAC_ADMIN and that is allowed 
mac_admin permission in SELinux policy (or if SELinux is permissive) sets a 
security.selinux xattr with an embedded NUL on a file and then it or any other 
process performs a getxattr() on that file with a length greater than the 
length of the string up to the embedded NUL.  Is that accurate?  If so, then 
this is never possible on Android (no process is allowed mac_admin permission 
and SELinux is always enforcing) and is only possible in Fedora/RHEL for a few 
specific root/CAP_MAC_ADMIN processes in specific SELinux domains (sesearch -A 
-p mac_admin) if SELinux is enforcing or any root/CAP_MAC_ADMIN process if 
SELinux is permissive.  Regardless, not exploitable without CAP_MAC_ADMIN.  
Also possible with a crafted filesystem image that already contains such an 
xattr.

Generally we include the terminating NUL in the length, so context.len would be 
strlen(str)+1.  Otherwise, I think your fix is reasonable.  I think this bug 
goes back to 9a59daa03df72526d234b91dd3e32ded5aebd3ef ("SELinux: fix sleeping 
allocation in security_context_to_sid").
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: SELinux musl support

[Stephen Smalley]

On 05/18/2018 01:03 AM, Jason Zaman wrote:
> On Thu, May 17, 2018 at 09:22:01PM +0200, Nicolas Iooss wrote:
>> On Thu, May 17, 2018 at 7:11 AM, Jason Zaman  wrote:
>>> This series fixes compiling and running on musl libc.
>>>
>>> patches 1-2 are fairly trivial.
>>>
>>> patches 3-4 are a feature change on that platform since it does not
>>> support GLOB_TILDE and GLOB_BRACE. tilde is coming in musl 1.1.21
>>> according to [1]. brace support is not documented anywhere or in the
>>> example configs so that is probably not a big problem.
>>>
>>> patch 5 fixes a bug and it just happens that glibc returns a value for
>>> sysconf and the error handling was wrong but never noticed.
>>>
>>> [1]: https://wiki.musl-libc.org/roadmap.html
>>>
>>> [PATCH 1/5] sestatus: include limits.h for PATH_MAX
>>> [PATCH 2/5] libselinux: enable linking to musl-fts
>>> [PATCH 3/5] setfiles: Musl compatibility for GLOB_BRACE and
>>> [PATCH 4/5] restorecond: Musl compatibility for GLOB_BRACE and
>>> [PATCH 5/5] genhomedircon: sysconf can return -1 without failure
>>
>> Thanks! These patches look good to me and I would also appreciate if
>> they are merged in 2.8.
> 
> Awesome, I'll push them on monday then unless there are any issues
> before then :)

FWIW, the patches look fine to me as well and I did a test PR to trigger travis 
CI testing
and they passed,
https://github.com/SELinuxProject/selinux/pull/96

One possible area for improvement (but not necessary to merge this) would be to 
fix the
genhomedircon code to also then handle the case where getpwnam_r/getgrnam_r 
returns ERANGE,
in which case we are supposed to realloc a larger buffer and try again per the 
man page.

Re: ANN: SELinux userspace 2.8-rc3 release candidate

[Stephen Smalley]

On 05/16/2018 01:31 PM, Jason Zaman wrote:
> Just a quick note in case the release is soon.
> I have a couple patches to make everything work on
> Musl libc that im gonna clean them up and post in the morning.

Given that these have been merged and I've seen no other activity, I assume we 
can make a final 2.8 release anytime.
If anyone objects, speak up now.

> 
> On Thu, May 10, 2018 at 11:20:01AM -0400, Stephen Smalley wrote:
>> A 2.8-rc3 release candidate for the SELinux userspace is now available at:
>> https://github.com/SELinuxProject/selinux/wiki/Releases
>>
>> Please give it a test and let us know if there are any issues.
>>
>> A draft of the release notes is available from the Releases page, as
>> is the full git log output and git shortlog output since the 2.7
>> release.  If there are further items we should mention or if something
>> should be amended in the release notes, let us know.
>>  
>> Thanks to all the contributors to this release candidate!
>>  
>> A shortlog of changes since the 2.8-rc2 release candidate is below.
>>
>> Stephen Smalley (7):
>>   libsepol: remove unused function and type
>>   libselinux: fix build warning in save_booleans()
>>   libselinux: avcstat: fix build warning
>>   libselinux: audit2why: fix build warnings
>>   libsemanage: prevent string overflow on final paths
>>   libsepol: cil: prevent stack buffer overflow in cil_expr_to_string
>>   Update VERSION files to 2.8-rc3
>>
>> Vit Mojzis (1):
>>   python/semanage/seobject.py: Fix undefined store check
> 
> 

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: is_selinux_enabled() after chroot()

[Stephen Smalley]

On 06/18/2018 03:24 PM, Petr Lautrbach wrote:
> Hello,
> 
> libselinux sets selinut_mnt and has_selinux_config only in its constructor and
> is_selinux_enabled() and others just use selinux_mnt to check if SELinux is
> enabled. But it doesn't work correctly when you use chroot() to a directory 
> without /proc
> and /sys/fs/selinux mounted as it was discovered in
> https://bugzilla.redhat.com/show_bug.cgi?id=1321375 
> 
> In this case, is_selinux_enabled() after chroot() returns true while in a new
> program run from chrooted process it returns false. It can be demonstrated by
> the steps below.
> 
> The solution could be to check if selinux_mnt still exists whenever a function
> depending on this is called. Would this be acceptable?

You want to call stat() or access(F_OK) on selinux_mnt and/or SELINUXCONFIG in 
is_selinux_enabled()?
Could potentially trigger a permission check that wasn't previously required, 
thereby breaking existing policies.
Caller might just be checking to see if SELinux is enabled before using 
interfaces other than selinuxfs (e.g. setexeccon, setfilecon, etc) and 
therefore didn't previously need permissions to selinuxfs or 
/etc/selinux/config.
So, possible but you'd need to make sure you don't break anything.  Definitely 
don't want that changed in Android.

> 
> 
> 
> 
> $ sudo dnf --nogpg --installroot=/var/lib/machines/example  install systemd
> 
> $ cat > test_libselinux.c < #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main(int argc, char *argv[]) {
>   pid_t pid;
>   int wstatus;
> 
>   if (argc > 1) {
> printf("SELinux in chrooted process: %d\n", is_selinux_enabled());
> return 0;
>   }
>   if (chroot("/var/lib/machines/example") != 0)
> return -1;
> 
>   printf("SELinux in process after chroot(): %d\n", is_selinux_enabled());
>   printf("/sys/fs/selinux exists: %d\n", access("/sys/fs/selinux", F_OK));
>   printf("/etc/selinux/config exists: %d\n\n", access("/etc/selinux/config", 
> F_OK));
> 
>   if ((pid = fork()) == 0 ) {
> execv("./test_is_selinux_enabled", (char *[]){ 
> "./test_is_selinux_enabled", "chrooted", NULL});
>   }
> 
>   wait();
>   return 0;
> }
> EOF
> 
> $ gcc -o test_is_selinux_enabled test_libselinux.c -lselinux
> 
> $ sudo ./test_is_selinux_enabled
> SELinux in process after chroot(): 1
> /sys/fs/selinux exists: -1
> /etc/selinux/config exists: -1
> 
> SELinux in chrooted process: 0
> 
> 
> 
> ___
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
> 

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: 'setsebool -P' works but throws errors; changes not permanent

[Stephen Smalley]

On 06/18/2018 03:44 PM, Mike Hughes wrote:
> We use Yubikey for two-factor ssh authentication which requires enabling a 
> Boolean called “authlogin_yubikey”. It has been working fine until a few 
> weeks ago. Errors appear when attempting to set the policy:
> 
>  
> 
> --
> 
> [Cent-7:root@my_server home]# getsebool authlogin_yubikey
> 
> authlogin_yubikey --> off
> 
>  
> 
> [Cent-7:root@my_server home]# setsebool -P authlogin_yubikey on
> 
> libsepol.context_from_record: type gpio_device_t is not defined
> 
> libsepol.context_from_record: could not create context structure
> 
> libsepol.context_from_string: could not create context structure
> 
> libsepol.sepol_context_to_sid: could not convert 
> system_u:object_r:gpio_device_t:s0 to sid
> 
> invalid context system_u:object_r:gpio_device_t:s0

Sounds like your policy is in an inconsistent internal state (somewhere you 
have a context with gpio_device_t but the type isn't defined in the policy).

What's your policy version?  And did it perhaps fail during %post when it was 
updated - check yum.log?

Does semodule -B fail?

Might have to move aside your policy and reinstall it.

> 
>  
> 
> [Cent-7:root@my_server home]# getsebool authlogin_yubikey
> 
> authlogin_yubikey --> on
> 
> ---
> 
>  
> 
> The system accepts two-factor while the above is set to “on”. After some 
> undetermined time (or immediately after a reboot) the Boolean toggles off. 
> This can be confirmed since semanage shows that the default is still set to 
> “off”:
> 
>  
> 
> --
> 
> [Cent-7:root@my_server ~]# semanage boolean -l | grep "authlogin_yubikey"
> 
> SELinux boolean    State  Default Description
> 
> ...
> 
> authlogin_yubikey  (on   ,  off)  Allow authlogin to yubikey
> 
> --
> 
>  
> 
> It looks similar to the following bug on Fedora:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1559174
> 
> 
> 
> ___
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
> 

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH 1/1] scripts: add a helper script to run clang's static analyzer

[Stephen Smalley]

On 06/09/2018 04:08 PM, Nicolas Iooss wrote:
> Using clang's static analyzer is as simple as running "scan-build make",
> but in order to obtain clean and reproducible results, the build
> environment has to be cleaned beforehand ("make clean distclean").
> 
> Moreover the project requires running "make install" before "make test"
> in order to install the dependencies needed for the tests, and running
> these tests with the newly-built libraries requires a specific
> LD_LIBRARY_PATH. This new script takes care of setting up everything
> which is needed.
> 
> Signed-off-by: Nicolas Iooss 

Thanks, applied.

> ---
>  scripts/.gitignore |  1 +
>  scripts/run-scan-build | 33 +
>  2 files changed, 34 insertions(+)
>  create mode 100644 scripts/.gitignore
>  create mode 100755 scripts/run-scan-build
> 
> diff --git a/scripts/.gitignore b/scripts/.gitignore
> new file mode 100644
> index ..54882b3b1507
> --- /dev/null
> +++ b/scripts/.gitignore
> @@ -0,0 +1 @@
> +/output-scan-build/
> diff --git a/scripts/run-scan-build b/scripts/run-scan-build
> new file mode 100755
> index ..8b24a4d04647
> --- /dev/null
> +++ b/scripts/run-scan-build
> @@ -0,0 +1,33 @@
> +#!/bin/sh
> +# Run clang's static analyzer (scan-build) and record its output in 
> output-scan-build/
> +
> +# Ensure the current directory is where this script is
> +cd "$(dirname -- "$0")" || exit $?
> +
> +OUTPUTDIR="$(pwd)/output-scan-build"
> +
> +# Display the commands which are run, and make sure they succeed
> +set -x -e
> +
> +# Use a temporary directory as an installation directory, if $DESTDIR is not 
> set
> +if [ -z "$DESTDIR" ] ; then
> +DESTDIR="$(mktemp --tmpdir -d scan-build-destdir-XX)"
> +fi
> +
> +# Make sure to use the newly-installed libraries when running tests
> +export LD_LIBRARY_PATH="$DESTDIR/usr/lib:$DESTDIR/lib"
> +export 
> PATH="$DESTDIR/usr/sbin:$DESTDIR/usr/bin:$DESTDIR/sbin:$DESTDIR/bin:$PATH"
> +export PYTHONPATH="$DESTDIR$(${PYTHON:-python} -c "from distutils.sysconfig 
> import *;print(get_python_lib(prefix='/usr'))")"
> +export RUBYLIB="$DESTDIR/$(${RUBY:-ruby} -e 'puts 
> RbConfig::CONFIG["vendorlibdir"]'):$DESTDIR/$(${RUBY:-ruby} -e 'puts 
> RbConfig::CONFIG["vendorarchdir"]')"
> +
> +# Build and analyze
> +make -C .. CC=clang clean distclean -j"$(nproc)"
> +scan-build -analyze-headers -o "$OUTPUTDIR" make -C .. CC=clang 
> DESTDIR="$DESTDIR" install install-pywrap install-rubywrap all test
> +
> +# Reduce the verbosity in order to keep the message from scan-build saying
> +# "scan-build: Run 'scan-view /.../output-scan-build/2018-...' to examine 
> bug reports.
> +set +x
> +
> +# Remove the destination directory without using "rm -rf"
> +chmod u+w "$DESTDIR/usr/bin/newrole"
> +rm -r "$DESTDIR"
> 

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH 3/3] libsepol/cil: use a colon instead of a semicolon to report rc

[Stephen Smalley]

On 06/09/2018 03:30 PM, Nicolas Iooss wrote:
> Signed-off-by: Nicolas Iooss 

Thanks, applied all three.

> ---
>  libsepol/cil/src/cil_resolve_ast.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libsepol/cil/src/cil_resolve_ast.c 
> b/libsepol/cil/src/cil_resolve_ast.c
> index 02259241ddfe..fb9d91745629 100644
> --- a/libsepol/cil/src/cil_resolve_ast.c
> +++ b/libsepol/cil/src/cil_resolve_ast.c
> @@ -2923,7 +2923,7 @@ int cil_resolve_call1(struct cil_tree_node *current, 
> void *extra_args)
>  
>   rc = cil_fill_ipaddr(pc->cl_head, 
> ipaddr);
>   if (rc != SEPOL_OK) {
> - cil_log(CIL_ERR, "Failed to 
> create anonymous ip address, rc; %d\n", rc);
> + cil_log(CIL_ERR, "Failed to 
> create anonymous ip address, rc: %d\n", rc);
>   cil_destroy_ipaddr(ipaddr);
>   goto exit;
>   }
> 

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: fixfiles and load_policy moved from /sbin to /usr/sbin

[Stephen Smalley]

On 05/29/2018 02:28 PM, Stephen Smalley wrote:
> On 05/29/2018 11:19 AM, Laurent Bigonville wrote:
>> Hello,
>>
>> While packaging policycoreutils 2.8 I've seen that the fixfiles and 
>> load_policy executables were moved from /sbin to /usr/sbin
>>
>> Any reasons for this? This seems to me like an involuntary side effect of 
>> the cleanup for DESTDIR and PREFIX in the build system.
>>
>> For distribution with usr-merge that will not change anything, but for 
>> others that could prevent early boot scripts to load the policy
>>
>> Shouldn't that be reverted?
> 
> Yes, I think that was an oversight.  However, generally policy loading is 
> handled directly by init (both sysvinit and systemd) via libselinux w/o 
> executing the load_policy executable, and libsemanage checks both locations 
> for it, so I wouldn't expect policy loading to be broken.  fixfiles 
> invocation from init scripts may be a different matter.  Likely should revert 
> the location change for both (but not the rest of DESTDIR/PREFIX fixes).

I guess the change might break systems calling load_policy from dracut 
initramfs scripts to load policy instead of calling libselinux from init, e.g. 
RHEL 6.  I'm not sure though that any distro other than RHEL 6 ever did that.

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: fixfiles and load_policy moved from /sbin to /usr/sbin

[Stephen Smalley]

On 05/29/2018 11:19 AM, Laurent Bigonville wrote:
> Hello,
> 
> While packaging policycoreutils 2.8 I've seen that the fixfiles and 
> load_policy executables were moved from /sbin to /usr/sbin
> 
> Any reasons for this? This seems to me like an involuntary side effect of the 
> cleanup for DESTDIR and PREFIX in the build system.
> 
> For distribution with usr-merge that will not change anything, but for others 
> that could prevent early boot scripts to load the policy
> 
> Shouldn't that be reverted?

Yes, I think that was an oversight.  However, generally policy loading is 
handled directly by init (both sysvinit and systemd) via libselinux w/o 
executing the load_policy executable, and libsemanage checks both locations for 
it, so I wouldn't expect policy loading to be broken.  fixfiles invocation from 
init scripts may be a different matter.  Likely should revert the location 
change for both (but not the rest of DESTDIR/PREFIX fixes).



___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH] selinux: KASAN: slab-out-of-bounds in xattr_getsecurity

[Stephen Smalley]

On 05/30/2018 11:19 AM, Paul Moore wrote:
> On Fri, May 25, 2018 at 4:31 AM, Sachin Grover  wrote:
>> Call trace:
>>  [] dump_backtrace+0x0/0x428
>>  [] show_stack+0x28/0x38
>>  [] dump_stack+0xd4/0x124
>>  [] print_address_description+0x68/0x258
>>  [] kasan_report.part.2+0x228/0x2f0
>>  [] kasan_report+0x5c/0x70
>>  [] check_memory_region+0x12c/0x1c0
>>  [] memcpy+0x34/0x68
>>  [] xattr_getsecurity+0xe0/0x160
>>  [] vfs_getxattr+0xc8/0x120
>>  [] getxattr+0x100/0x2c8
>>  [] SyS_fgetxattr+0x64/0xa0
>>  [] el0_svc_naked+0x24/0x28
>>
>> If user get root access and calls security.selinux setxattr() with an
>> embedded NUL on a file and then if some process performs a getxattr()
>> on that file with a length greater than the actual length of the string,
>> it would result in a panic.
>>
>> To fix this, add the actual length of the string to the security context
>> instead of the length passed by the userspace process.
>>
>> Signed-off-by: Sachin Grover 
>> ---
>>  security/selinux/ss/services.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Thanks for reporting this and providing a patch.  It's small enough,
> and passes all the regular tests, so I've merged it into
> selinux/stable-4.17 (adding the stable metadata) and I'm going to send
> it up to Linus today.
> 
> If Linus doesn't pull the fix in time for v4.17 I'll send it up during
> the upcoming merge window.

NB Such a setxattr() call can only be performed by a process with CAP_MAC_ADMIN 
that is also allowed mac_admin permission in SELinux policy. Consequently, this 
is never possible on Android (no process is allowed mac_admin permission, 
always enforcing) and is only possible in Fedora/RHEL for a few domains (if 
enforcing).

Fixes: 9a59daa03df72526d234b91dd3e32ded5aebd3ef ("SELinux: fix sleeping 
allocation in security_context_to_sid")

> 
>> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
>> index 66ea81c..d17f5b4 100644
>> --- a/security/selinux/ss/services.c
>> +++ b/security/selinux/ss/services.c
>> @@ -1434,7 +1434,7 @@ static int security_context_to_sid_core(const char 
>> *scontext, u32 scontext_len,
>>   scontext_len, , def_sid);
>> if (rc == -EINVAL && force) {
>> context.str = str;
>> -   context.len = scontext_len;
>> +   context.len = strlen(str) + 1;
>> str = NULL;
>> } else if (rc)
>> goto out_unlock;
>> --
>> 1.9.1
> 

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH V3 0/5] selinux:Significant reduce of preempt_disable holds

[Stephen Smalley]

On 05/30/2018 10:10 AM, Peter Enderborg wrote:
> Holding the preempt_disable is very bad for low latency tasks
> such as audio and therefore we need to break out the rule-set dependent
> part from this disable. By using a RCU instead of rwlock we
> have an efficient locking and less preemption interference.
> 
> Selinux uses a lot of read_locks. This patch replaces the rwlock
> with RCU that does not hold preempt_disable.
> 
> Intel Xeon W3520 2.67 Ghz running FC27 with 4.15.0-rc9git (+measurement)
> I get preempt_disable of about 1.2ms in security_compute_av().
> With the patch I get 960us as the longest security_compute_av()
> without preempt disabeld. There are very much noise in the measurement
> but it is not likely a degrade.
> 
> And the preempt_disable times is also very dependent on the selinux
> rule-set.
> 
> In security_get_user_sids() we have two nested for-loops and the
> inner part calls sittab_context_to_sid() that calls
> sidtab_search_context() that has a for loop() over a while() where
> the loops is dependent on the rules.
> 
> On the test system the average lookup time is 60us and does
> not change with the introduced RCU usage.
> 
> The boolean change becomes a lot more heavy with this patch,
> but it is a very rare usage in compare with read only operations.
> The lock held during a policydb_copy is about 1ms on a XEON.

This has a very substantial performance impact on setsebool, e.g. time 
setsebool httpd_can_sendmail=1.
That's because you are doing a full 
vmalloc();policydb_write();policydb_read();vfree() sequence on it.
In comparison, KaiGai's old attempt to replace the policy rwlock with RCU only 
duplicated the conditional policydb state (via a cond_policydb_dup) that he 
introduced.  Is there a reason you couldn't use that approach?

> 
> To use RCU the structure of policydb has to be accesses through a pointer.
> We need 5 patches to get there.
>  
> [PATCH V3 1/5 selinux-next] selinux: Make allocation atomic in policydb 
> objects functions.
> This patch change the allocation for policydb objects. They are in its own 
> patch
> to make the complicated part easier to read.
> 
> [PATCH V3 2/5 selinux-next] selinux: Introduce selinux_ruleset struct
> This makes the access for the rule evaluation going though a single pointer.
> 
> [PATCH V3 3/5 selinux-next] selinux: sidtab_clone switch to use rwlock.
> We need to make sidtabs copys so this patch change the locks to a rwlock
> and create a copy function.
> 
> [PATCH V3 4/5 selinux-next] selinux: seqno separation
> This patch adds separation of the read and write and uses
> the pointer to switch rule set. It uses seqno for error handling
> since there are a possibility to have multiple access.
> 
> [PATCH V3 5/5 selinux-next] selinux: Switch to rcu read locks for avc_compute
> All the preparation is done so this patch do the change of locks to rcu.
> 
> History:
> V1 rwsem
> V2 did not handle all policydb objects, solved with the policydb_copy
>did not handle sidtab for booleans, I think this one does however
>shutdown is not used but not removed. 
> 
> 

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH V3 0/5] selinux:Significant reduce of preempt_disable holds

[Stephen Smalley]

On 05/31/2018 05:04 AM, peter enderborg wrote:
> On 05/30/2018 10:34 PM, Stephen Smalley wrote:
>> On 05/30/2018 10:10 AM, Peter Enderborg wrote:
>>> The boolean change becomes a lot more heavy with this patch,
>>> but it is a very rare usage in compare with read only operations.
>>> The lock held during a policydb_copy is about 1ms on a XEON.
>> This has a very substantial performance impact on setsebool, e.g. time 
>> setsebool httpd_can_sendmail=1.
>> That's because you are doing a full 
>> vmalloc();policydb_write();policydb_read();vfree() sequence on it.
>> In comparison, KaiGai's old attempt to replace the policy rwlock with RCU 
>> only duplicated the conditional policydb state (via a cond_policydb_dup) 
>> that he introduced.  Is there a reason you couldn't use that approach?
> That one did not make it, so I went for a other path. Make it simple, using 
> the same serialisation that exist. That also make it easier to maintain.
> We do not  use the booleans in android since they are not allowed so im not 
> aware of any use case where this administrative function are
> used in such frequent manner that it would have an impact. And it must be 
> some other large overhead with interprocess communication and
> a multiple writes to sysfs during a boolean settings?  However my concern 
> is/was memory pressure, setting booleans will generate pressure
> with lot of atomic allocation and large vmallocs.

Yes, that is also a concern.  I would prefer to only duplicate the conditional 
policydb state as in KaiGai's patch.
Keeping temporary setting of booleans lightweight is desirable for other use 
cases than Android.

I'm also concerned by the implications of switching all of the allocations to 
atomic.  KaiGai's patch did not take that approach either, and it obviously 
could make policy reload more prone to transient failures.

 But my goal is the fast path for real time critical functions such as audio, 
and it will be a cost for
> administrative tasks. On the xeon it takes about ~98 ms to run the 
> security_set_bools compared to about ~8 ms without the overhead
> of copying the policydb.  About ~6 ms is rcu sync and ~8 ms is the same as 
> the original update of selinux statuses, and about ~25 ms
> is policydb_destroy() of the old copy.
>>



___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: Invalid security context while executing audit2alllow.orig

[Stephen Smalley]

On 05/29/2018 07:39 AM, bhawna goel wrote:
> Hi Team,
> 
> We are getting below error while creating policies using command 
> audit2allow.orig. Can you help in identifying what could be the possible 
> reason of such error.
> 
> Error:
> libsepol.context_from_record: invalid security context: 
> "specialuser_u:system_r:ssh_t:s0"
> libsepol.context_from_record: could not create context structure
> libsepol.context_from_string: could not create context structure
> libsepol.sepol_context_to_sid: could not convert 
> specialuser_u:system_r:ssh_t:s0 to sid

This means that a security context from the avc messages that you fed into 
audit2allow (or read from the audit logs) is not valid under the currently 
loaded policy, e.g. specialuser_u might not be defined or it might not be 
authorized for the system_r role.

This commonly happens when you take avc denials / audit logs from one system 
and try to apply audit2allow to them on a different system with a different 
policy, or if the denials occurred while a different policy was loaded.

You can specify a policy to audit2allow via -p and have it use that policy when 
decoding the security contexts.
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH V3 0/5] selinux:Significant reduce of preempt_disable holds

[Stephen Smalley]

On 05/31/2018 10:21 AM, Stephen Smalley wrote:
> On 05/31/2018 10:12 AM, peter enderborg wrote:
>> On 05/31/2018 02:42 PM, Stephen Smalley wrote:
>>> On 05/31/2018 05:04 AM, peter enderborg wrote:
>>>> On 05/30/2018 10:34 PM, Stephen Smalley wrote:
>>>>> On 05/30/2018 10:10 AM, Peter Enderborg wrote:
>>>>>> The boolean change becomes a lot more heavy with this patch,
>>>>>> but it is a very rare usage in compare with read only operations.
>>>>>> The lock held during a policydb_copy is about 1ms on a XEON.
>>>>> This has a very substantial performance impact on setsebool, e.g. time 
>>>>> setsebool httpd_can_sendmail=1.
>>>>> That's because you are doing a full 
>>>>> vmalloc();policydb_write();policydb_read();vfree() sequence on it.
>>>>> In comparison, KaiGai's old attempt to replace the policy rwlock with RCU 
>>>>> only duplicated the conditional policydb state (via a cond_policydb_dup) 
>>>>> that he introduced.  Is there a reason you couldn't use that approach?
>>>> That one did not make it, so I went for a other path. Make it simple, 
>>>> using the same serialisation that exist. That also make it easier to 
>>>> maintain.
>>>> We do not  use the booleans in android since they are not allowed so im 
>>>> not aware of any use case where this administrative function are
>>>> used in such frequent manner that it would have an impact. And it must be 
>>>> some other large overhead with interprocess communication and
>>>> a multiple writes to sysfs during a boolean settings?  However my concern 
>>>> is/was memory pressure, setting booleans will generate pressure
>>>> with lot of atomic allocation and large vmallocs.
>>> Yes, that is also a concern.  I would prefer to only duplicate the 
>>> conditional policydb state as in KaiGai's patch.
>>> Keeping temporary setting of booleans lightweight is desirable for other 
>>> use cases than Android.
>>>
>>> I'm also concerned by the implications of switching all of the allocations 
>>> to atomic.  KaiGai's patch did not take that approach either, and it 
>>> obviously could make policy reload more prone to transient failures.
>>
>> On the version 2 of the patchset you pointed out that I did a shallow copy, 
>> so I did a "deap" copy. As I see it the KaiGai cond_policydb_dup also do a 
>> shallow copy.
> 
> In your earlier patch set, you just did a memcpy of the policydb and then 
> proceeded to mutate parts of the conditional policydb state, which would have 
> modified the original too.  KaiGai was performing a deep copy of the 
> conditional portions of the policydb I believe.
> 
>> You dont happend to know exactly why KaiGai's patch never was accepted?
> 
> As I recall, there wasn't anything wrong with the code itself; he just wasn't 
> satisfied that it ended up being a worthwhile tradeoff based on his own 
> performance testing.

His use case however was different - he was concerned with networking 
performance, and the introduction of the netnode/netport caches largely 
eliminated the policy rwlock as a concern there.

> 
>>
>>>  But my goal is the fast path for real time critical functions such as 
>>> audio, and it will be a cost for
>>>> administrative tasks. On the xeon it takes about ~98 ms to run the 
>>>> security_set_bools compared to about ~8 ms without the overhead
>>>> of copying the policydb.  About ~6 ms is rcu sync and ~8 ms is the same as 
>>>> the original update of selinux statuses, and about ~25 ms
>>>> is policydb_destroy() of the old copy.
>>>
>>>
>>>

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: BTRFS losing SE Linux labels on power failure or "reboot -nffd".

[Stephen Smalley]

On 06/01/2018 09:03 AM, Russell Coker via Selinux wrote:
> The command "reboot -nffd" (kernel reboot without flushing kernel buffers or 
> writing status) when run on a BTRFS system will often result in 
> /var/log/audit/audit.log being unlabeled. It also results in some 
> systemd-journald files like 
> /var/log/journal/c195779d29154ed8bcb4e8444c4a1728/system.journal being 
> unlabeled but that is rarer. I think that the same problem afflicts both 
> systemd-journald and auditd but it's a race condition that on my systems 
> (both production and test) is more likely to affect auditd.
> 
>  
> 
> If this issue just affected "reboot -nffd" then a solution might be to just 
> not run that command. However this affects systems after a power outage.
> 
>  
> 
> I have reproduced this bug with kernel 4.9.0-6-amd64 (the latest security 
> update for Debian/Stretch which is the latest supported release of Debian). I 
> have also reported it in an identical manner with kernel 4.16.0-1-amd64 (the 
> latest from Debian/Unstable). For testing I reproduced this with a 4G 
> filesystem in a VM, but in production it has happened on BTRFS RAID-1 arrays, 
> both SSD and HDD.
> 
>  
> 
> #!/bin/bash
> set -e
> COUNT=$(ps aux|grep [s]bin/auditd|wc -l)
> date
> if [ "$COUNT" = "1" ]; then
>  echo "all good"
> else
>  echo "failed"
>  exit 1
> fi
> 
> Firstly the above is the script /usr/local/sbin/testit, I test for auditd 
> running because it aborts if the context on it's log file is wrong.
> 
>  
> 
> root@stretch:~# ls -liZ /var/log/audit/audit.log
> 37952 -rw---. 1 root root system_u:object_r:auditd_log_t:s0 4385230 Jun  
> 1 12:23 /var/log/audit/audit.log
> 
> Above is before I do the tests.
> 
>  
> 
> while ssh stretch /usr/local/sbin/testit ; do
>  ssh btrfs-local "reboot -nffd" > /dev/null 2>&1 &
>  sleep 20
> done
> 
> Above is the shell code I run to do the tests. Note that the VM in question 
> runs on SSD storage which is why it can consistently boot in less than 20 
> seconds.
> 
>  
> 
> Fri  1 Jun 12:26:13 UTC 2018
> all good
> Fri  1 Jun 12:26:33 UTC 2018
> failed
> 
> Above is the output from the shell code in question. After the first reboot 
> it fails. The probability of failure on my test system is greater than 50%.
> 
>  
> 
> root@stretch:~# ls -liZ /var/log/audit/audit.log  
> 37952 -rw---. 1 root root system_u:object_r:unlabeled_t:s0 4396803 Jun  1 
> 12:26 /var/log/audit/audit.log
> 
> Now the result. Note that the Inode has not changed. I could understand a 
> newly created file missing an xattr, but this is an existing file which 
> shouldn't have had it's xattr changed. But somehow it gets corrupted.
> 
>  
> 
> Could this be the fault of SE Linux code? I don't think it's likely but this 
> is what the BTRFS developers will ask so it's best to discuss this here 
> before sending it to them.

No, that's definitely a filesystem bug.  It is the filesystem's responsibility 
to ensure that new inodes are assigned a security.* xattr in the same 
transaction as the file creation (ext[234] does this, for example, e.g. via 
ext4_init_security()), and that they don't lose them.  SELinux just provides 
the xattr suffix ("selinux") and the value/value_len pair.

> 
>  
> 
> Does anyone have any ideas of other tests I should run? Anyone want me to try 
> a different kernel? I can give root on a VM to anyone who wants to poke at 
> it. Anything else I should add when sending this to the BTRFS developers?

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH 4/4] policycoreutils/hll/pp: remove unused variable

[Stephen Smalley]

On 06/03/2018 12:25 PM, Nicolas Iooss wrote:
> pp's main() never set outfd to anything else than -1 so there is no
> point in closing it.

Thanks, applied all four patches.

> 
> Signed-off-by: Nicolas Iooss 
> ---
>  policycoreutils/hll/pp/pp.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/policycoreutils/hll/pp/pp.c b/policycoreutils/hll/pp/pp.c
> index b97a9b34816a..98969eb2f5f3 100644
> --- a/policycoreutils/hll/pp/pp.c
> +++ b/policycoreutils/hll/pp/pp.c
> @@ -73,7 +73,6 @@ int main(int argc, char **argv)
>   const char *ofile = NULL;
>   FILE *in = NULL;
>   FILE *out = NULL;
> - int outfd = -1;
>  
>   // ignore sigpipe so we can check the return code of write, and 
> potentially
>   // return a more helpful error message
> @@ -159,12 +158,6 @@ exit:
>   if (out != NULL) {
>   fclose(out);
>   }
> - if (outfd != -1) {
> - close(outfd);
> - if (rc != 0) {
> - unlink(argv[2]);
> - }
> - }
>   sepol_module_package_free(mod_pkg);
>  
>   return rc;
> 

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH V3 0/5] selinux:Significant reduce of preempt_disable holds

[Stephen Smalley]

On 05/31/2018 10:12 AM, peter enderborg wrote:
> On 05/31/2018 02:42 PM, Stephen Smalley wrote:
>> On 05/31/2018 05:04 AM, peter enderborg wrote:
>>> On 05/30/2018 10:34 PM, Stephen Smalley wrote:
>>>> On 05/30/2018 10:10 AM, Peter Enderborg wrote:
>>>>> The boolean change becomes a lot more heavy with this patch,
>>>>> but it is a very rare usage in compare with read only operations.
>>>>> The lock held during a policydb_copy is about 1ms on a XEON.
>>>> This has a very substantial performance impact on setsebool, e.g. time 
>>>> setsebool httpd_can_sendmail=1.
>>>> That's because you are doing a full 
>>>> vmalloc();policydb_write();policydb_read();vfree() sequence on it.
>>>> In comparison, KaiGai's old attempt to replace the policy rwlock with RCU 
>>>> only duplicated the conditional policydb state (via a cond_policydb_dup) 
>>>> that he introduced.  Is there a reason you couldn't use that approach?
>>> That one did not make it, so I went for a other path. Make it simple, using 
>>> the same serialisation that exist. That also make it easier to maintain.
>>> We do not  use the booleans in android since they are not allowed so im not 
>>> aware of any use case where this administrative function are
>>> used in such frequent manner that it would have an impact. And it must be 
>>> some other large overhead with interprocess communication and
>>> a multiple writes to sysfs during a boolean settings?  However my concern 
>>> is/was memory pressure, setting booleans will generate pressure
>>> with lot of atomic allocation and large vmallocs.
>> Yes, that is also a concern.  I would prefer to only duplicate the 
>> conditional policydb state as in KaiGai's patch.
>> Keeping temporary setting of booleans lightweight is desirable for other use 
>> cases than Android.
>>
>> I'm also concerned by the implications of switching all of the allocations 
>> to atomic.  KaiGai's patch did not take that approach either, and it 
>> obviously could make policy reload more prone to transient failures.
> 
> On the version 2 of the patchset you pointed out that I did a shallow copy, 
> so I did a "deap" copy. As I see it the KaiGai cond_policydb_dup also do a 
> shallow copy.

In your earlier patch set, you just did a memcpy of the policydb and then 
proceeded to mutate parts of the conditional policydb state, which would have 
modified the original too.  KaiGai was performing a deep copy of the 
conditional portions of the policydb I believe.

> You dont happend to know exactly why KaiGai's patch never was accepted?

As I recall, there wasn't anything wrong with the code itself; he just wasn't 
satisfied that it ended up being a worthwhile tradeoff based on his own 
performance testing.

> 
>>  But my goal is the fast path for real time critical functions such as 
>> audio, and it will be a cost for
>>> administrative tasks. On the xeon it takes about ~98 ms to run the 
>>> security_set_bools compared to about ~8 ms without the overhead
>>> of copying the policydb.  About ~6 ms is rcu sync and ~8 ms is the same as 
>>> the original update of selinux statuses, and about ~25 ms
>>> is policydb_destroy() of the old copy.
>>
>>
>>
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH] python/semanage: Stop logging loginRecords changes

[Stephen Smalley]

On 06/18/2018 01:22 PM, Vit Mojzis wrote:
> semanage_seuser_modify_local and semanage_seuser_del_local already do
> the logging.
> Moreover, semanage log for loginRecords.__add was flawed since it
> reported old-{seuser,role,range} of default user instead of None. This
> was caused by selinux.getseuserbyname, which returns values for default
> user when the specified username is not found.
> 
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1294663

Thanks, applied.

> 
> Signed-off-by: Vit Mojzis 
> ---
>  python/semanage/seobject.py | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/python/semanage/seobject.py b/python/semanage/seobject.py
> index c76dce85..d3e14a8b 100644
> --- a/python/semanage/seobject.py
> +++ b/python/semanage/seobject.py
> @@ -593,7 +593,6 @@ class loginRecords(semanageRecords):
>  
>  semanage_seuser_key_free(k)
>  semanage_seuser_free(u)
> -self.mylog.log("login", name, sename=sename, serange=serange, 
> serole=",".join(serole), oldserole=",".join(oldserole), 
> oldsename=self.oldsename, oldserange=self.oldserange)
>  
>  def add(self, name, sename, serange):
>  try:
> @@ -601,7 +600,6 @@ class loginRecords(semanageRecords):
>  self.__add(name, sename, serange)
>  self.commit()
>  except ValueError as error:
> -self.mylog.commit(0)
>  raise error
>  
>  def __modify(self, name, sename="", serange=""):
> @@ -653,7 +651,6 @@ class loginRecords(semanageRecords):
>  
>  semanage_seuser_key_free(k)
>  semanage_seuser_free(u)
> -self.mylog.log("login", name, sename=self.sename, 
> serange=self.serange, serole=",".join(serole), oldserole=",".join(oldserole), 
> oldsename=self.oldsename, oldserange=self.oldserange)
>  
>  def modify(self, name, sename="", serange=""):
>  try:
> @@ -661,7 +658,6 @@ class loginRecords(semanageRecords):
>  self.__modify(name, sename, serange)
>  self.commit()
>  except ValueError as error:
> -self.mylog.commit(0)
>  raise error
>  
>  def __delete(self, name):
> @@ -694,8 +690,6 @@ class loginRecords(semanageRecords):
>  rec, self.sename, self.serange = 
> selinux.getseuserbyname("__default__")
>  range, (rc, serole) = userrec.get(self.sename)
>  
> -self.mylog.log_remove("login", name, sename=self.sename, 
> serange=self.serange, serole=",".join(serole), oldserole=",".join(oldserole), 
> oldsename=self.oldsename, oldserange=self.oldserange)
> -
>  def delete(self, name):
>  try:
>  self.begin()
> @@ -703,7 +697,6 @@ class loginRecords(semanageRecords):
>  self.commit()
>  
>  except ValueError as error:
> -self.mylog.commit(0)
>  raise error
>  
>  def deleteall(self):
> @@ -717,7 +710,6 @@ class loginRecords(semanageRecords):
>  self.__delete(semanage_seuser_get_name(u))
>  self.commit()
>  except ValueError as error:
> -self.mylog.commit(0)
>  raise error
>  
>  def get_all_logins(self):
> 

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH] selinux: move user accesses in selinuxfs out of locked regions

[Stephen Smalley]

On 06/25/2018 12:34 PM, Jann Horn wrote:
> If a user is accessing a file in selinuxfs with a pointer to a userspace
> buffer that is backed by e.g. a userfaultfd, the userspace access can
> stall indefinitely, which can block fsi->mutex if it is held.
> 
> For sel_read_policy(), remove the locking, since this method doesn't seem
> to access anything that requires locking.
> 
> For sel_read_bool(), move the user access below the locked region.
> 
> For sel_write_bool() and sel_commit_bools_write(), move the user access
> up above the locked region.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Jann Horn 

Only question I have is wrt the Fixes line, i.e. was this an issue until 
userfaultfd was introduced, and if not,
do we need it to be back-ported any further than the commit which introduced it.

Otherwise, you can add my
Acked-by: Stephen Smalley 

> ---
>  security/selinux/selinuxfs.c | 77 
>  1 file changed, 33 insertions(+), 44 deletions(-)
> 
> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> index f3d374d2ca04..065f8cea84e3 100644
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@ -445,18 +445,13 @@ static ssize_t sel_read_policy(struct file *filp, char 
> __user *buf,
>   struct policy_load_memory *plm = filp->private_data;
>   int ret;
>  
> - mutex_lock(>mutex);
> -
>   ret = avc_has_perm(_state,
>  current_sid(), SECINITSID_SECURITY,
> SECCLASS_SECURITY, SECURITY__READ_POLICY, NULL);
>   if (ret)
> - goto out;
> + return ret;
>  
> - ret = simple_read_from_buffer(buf, count, ppos, plm->data, plm->len);
> -out:
> - mutex_unlock(>mutex);
> - return ret;
> + return simple_read_from_buffer(buf, count, ppos, plm->data, plm->len);
>  }
>  
>  static vm_fault_t sel_mmap_policy_fault(struct vm_fault *vmf)
> @@ -1188,25 +1183,29 @@ static ssize_t sel_read_bool(struct file *filep, char 
> __user *buf,
>   ret = -EINVAL;
>   if (index >= fsi->bool_num || strcmp(name,
>fsi->bool_pending_names[index]))
> - goto out;
> + goto out_unlock;
>  
>   ret = -ENOMEM;
>   page = (char *)get_zeroed_page(GFP_KERNEL);
>   if (!page)
> - goto out;
> + goto out_unlock;
>  
>   cur_enforcing = security_get_bool_value(fsi->state, index);
>   if (cur_enforcing < 0) {
>   ret = cur_enforcing;
> - goto out;
> + goto out_unlock;
>   }
>   length = scnprintf(page, PAGE_SIZE, "%d %d", cur_enforcing,
> fsi->bool_pending_values[index]);
> - ret = simple_read_from_buffer(buf, count, ppos, page, length);
> -out:
>   mutex_unlock(>mutex);
> + ret = simple_read_from_buffer(buf, count, ppos, page, length);
> +out_free:
>   free_page((unsigned long)page);
>   return ret;
> +
> +out_unlock:
> + mutex_unlock(>mutex);
> + goto out_free;
>  }
>  
>  static ssize_t sel_write_bool(struct file *filep, const char __user *buf,
> @@ -1219,6 +1218,17 @@ static ssize_t sel_write_bool(struct file *filep, 
> const char __user *buf,
>   unsigned index = file_inode(filep)->i_ino & SEL_INO_MASK;
>   const char *name = filep->f_path.dentry->d_name.name;
>  
> + if (count >= PAGE_SIZE)
> + return -ENOMEM;
> +
> + /* No partial writes. */
> + if (*ppos != 0)
> + return -EINVAL;
> +
> + page = memdup_user_nul(buf, count);
> + if (IS_ERR(page))
> + return PTR_ERR(page);
> +
>   mutex_lock(>mutex);
>  
>   length = avc_has_perm(_state,
> @@ -1233,22 +1243,6 @@ static ssize_t sel_write_bool(struct file *filep, 
> const char __user *buf,
>fsi->bool_pending_names[index]))
>   goto out;
>  
> - length = -ENOMEM;
> - if (count >= PAGE_SIZE)
> - goto out;
> -
> - /* No partial writes. */
> - length = -EINVAL;
> - if (*ppos != 0)
> - goto out;
> -
> - page = memdup_user_nul(buf, count);
> - if (IS_ERR(page)) {
> - length = PTR_ERR(page);
> - page = NULL;
> - goto out;
> - }
> -
>   length = -EINVAL;
>   if (sscanf(page, "%d", _value) != 1)
>   goto out;
> @@ -1280,6 +1274,17 @@ static ssize_t s

Re: [PATCH] selinux: move user accesses in selinuxfs out of locked regions

[Stephen Smalley]

On 06/26/2018 08:42 AM, Jann Horn wrote:
> On Tue, Jun 26, 2018 at 2:15 PM Stephen Smalley  wrote:
>>
>> On 06/25/2018 12:34 PM, Jann Horn wrote:
>>> If a user is accessing a file in selinuxfs with a pointer to a userspace
>>> buffer that is backed by e.g. a userfaultfd, the userspace access can
>>> stall indefinitely, which can block fsi->mutex if it is held.
>>>
>>> For sel_read_policy(), remove the locking, since this method doesn't seem
>>> to access anything that requires locking.
>>>
>>> For sel_read_bool(), move the user access below the locked region.
>>>
>>> For sel_write_bool() and sel_commit_bools_write(), move the user access
>>> up above the locked region.
>>>
>>> Cc: sta...@vger.kernel.org
>>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>>> Signed-off-by: Jann Horn 
>>
>> Only question I have is wrt the Fixes line, i.e. was this an issue until 
>> userfaultfd was introduced, and if not,
>> do we need it to be back-ported any further than the commit which introduced 
>> it.
> 
> You can also use FUSE, if the system is configured appropriately:
> Mount a FUSE filesystem, mmap() a file from it, then pass a pointer to
> the mmapped region to a syscall. AFAICS FUSE was added to the kernel
> in commit d8a5ba45457e4a22aa39c939121efd7bb6c76672, first in
> v2.6.16.28.

Ok, then I guess it would be splitting hairs to not just take it all the way 
back.

> 
>> Otherwise, you can add my
>> Acked-by: Stephen Smalley 
> 
> This patch should go through Paul Moore's tree, right?

Yes, thanks.

> 
>>> ---
>>>  security/selinux/selinuxfs.c | 77 
>>>  1 file changed, 33 insertions(+), 44 deletions(-)
>>>
>>> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
>>> index f3d374d2ca04..065f8cea84e3 100644
>>> --- a/security/selinux/selinuxfs.c
>>> +++ b/security/selinux/selinuxfs.c
>>> @@ -445,18 +445,13 @@ static ssize_t sel_read_policy(struct file *filp, 
>>> char __user *buf,
>>>   struct policy_load_memory *plm = filp->private_data;
>>>   int ret;
>>>
>>> - mutex_lock(>mutex);
>>> -
>>>   ret = avc_has_perm(_state,
>>>  current_sid(), SECINITSID_SECURITY,
>>> SECCLASS_SECURITY, SECURITY__READ_POLICY, NULL);
>>>   if (ret)
>>> - goto out;
>>> + return ret;
>>>
>>> - ret = simple_read_from_buffer(buf, count, ppos, plm->data, plm->len);
>>> -out:
>>> - mutex_unlock(>mutex);
>>> - return ret;
>>> + return simple_read_from_buffer(buf, count, ppos, plm->data, plm->len);
>>>  }
>>>
>>>  static vm_fault_t sel_mmap_policy_fault(struct vm_fault *vmf)
>>> @@ -1188,25 +1183,29 @@ static ssize_t sel_read_bool(struct file *filep, 
>>> char __user *buf,
>>>   ret = -EINVAL;
>>>   if (index >= fsi->bool_num || strcmp(name,
>>>fsi->bool_pending_names[index]))
>>> - goto out;
>>> + goto out_unlock;
>>>
>>>   ret = -ENOMEM;
>>>   page = (char *)get_zeroed_page(GFP_KERNEL);
>>>   if (!page)
>>> - goto out;
>>> + goto out_unlock;
>>>
>>>   cur_enforcing = security_get_bool_value(fsi->state, index);
>>>   if (cur_enforcing < 0) {
>>>   ret = cur_enforcing;
>>> - goto out;
>>> + goto out_unlock;
>>>   }
>>>   length = scnprintf(page, PAGE_SIZE, "%d %d", cur_enforcing,
>>> fsi->bool_pending_values[index]);
>>> - ret = simple_read_from_buffer(buf, count, ppos, page, length);
>>> -out:
>>>   mutex_unlock(>mutex);
>>> + ret = simple_read_from_buffer(buf, count, ppos, page, length);
>>> +out_free:
>>>   free_page((unsigned long)page);
>>>   return ret;
>>> +
>>> +out_unlock:
>>> + mutex_unlock(>mutex);
>>> + goto out_free;
>>>  }
>>>
>>>  static ssize_t sel_write_bool(struct file *filep, const char __user *buf,
>>> @@ -1219,6 +1218,17 @@ static ssize_t sel_write_bool(struct file *filep, 
>>> const char __user *buf,
>>>   unsigned index = file_inode(filep)-