Re: [PATCH] selinux: wrap global selinux state

[Paul Moore]

On Thu, Mar 1, 2018 at 6:00 PM, Paul Moore  wrote:
> On Fri, Feb 16, 2018 at 12:19 PM, Stephen Smalley  wrote:
>> Define a selinux state structure (struct selinux_state) for
>> global SELinux state and pass it explicitly to all security server
>> functions.  The public portion of the structure contains state
>> that is used throughout the SELinux code, such as the enforcing mode.
>> The structure also contains a pointer to a selinux_ss structure whose
>> definition is private to the security server and contains security
>> server specific state such as the policy database and SID table.
>>
>> This change should have no effect on SELinux behavior or APIs
>> (userspace or LSM).  It merely wraps SELinux state and passes it
>> explicitly as needed.
>>
>> Signed-off-by: Stephen Smalley 
>> ---
>> This is effectively v2 of "selinux: introduce a selinux namespace",
>> but rewritten per the review to only perform the encapsulation of state
>> and rebased onto latest selinux/next, currently v4.16-rc1-based.
>> Changes from v1:
>> - Rename selinux_ns to selinux_state,
>> - Statically allocate selinux_state and selinux_ss,
>> - Drop any namespace-specific fields, code, and references,
>> - Use static inlines rather than macros.
>>
>> I also intend to rework the "selinux: support multiple selinuxfs instances"
>> and "selinux: move the AVC into the selinux namespace" patches similarly
>> and re-base on this one, but want to wait until this one is finalized since
>> every change to this own will require further reworking of the later ones.
>
> Thanks for the respin Stephen, I know that was probably a bit painful
> given the size of the patch; it definitely wasn't fun to review.  For
> the most part I think everything here looks fine (minor nitpick, see
> below), and because of these points:
>
> 1) Everything here is internal to SELinux so we change it without
> breaking userspace or even other parts of the kernel.
>
> 2) Other work is dependent on this patch.
>
> 3) A patch of this size and scopr, I want it in linux-next sooner
> rather than later.
>
> ... I'm going to merge this now, or rather as soon as my test kernel
> finishes building and I can give this a quick sanity check.

Quick sanity tests looked good, it's in selinux/next as of right now.

> As expected, there were some minor merge problems with the SCTP
> patches, but those were trivially fixed.
>
>> diff --git a/security/selinux/include/security.h 
>> b/security/selinux/include/security.h
>> index 02f0412d42f2..c3a1ef10e710 100644
>> --- a/security/selinux/include/security.h
>> +++ b/security/selinux/include/security.h
>
> ...
>
>> +static inline bool is_enforcing(struct selinux_state *state)
>> +static inline void set_enforcing(struct selinux_state *state, bool value)
>
> More nitpickery: I'm not a fan of these names.
>
> I'm going to take partial blame for this as I didn't pay close enough
> attention to the names earlier, I was focused on the #define vs inline
> function nature of the functions.  I realize it's late, and I want to
> get this merged (see above), so I'll put together a separate patch on
> top of this to change the names.

-- 
paul moore
www.paul-moore.com

[PATCH] selinux: rename the {is,set}_enforcing() functions

[Paul Moore]

From: Paul Moore 

Rename is_enforcing() to enforcing_enabled() and
enforcing_set() to set_enforcing().

Signed-off-by: Paul Moore 
---
 security/selinux/avc.c  |2 +-
 security/selinux/hooks.c|4 ++--
 security/selinux/include/security.h |8 
 security/selinux/selinuxfs.c|6 +++---
 security/selinux/ss/services.c  |6 +++---
 security/selinux/ss/status.c|2 +-
 6 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index 36124f48a5ff..54b09cc03b55 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -985,7 +985,7 @@ static noinline int avc_denied(u32 ssid, u32 tsid,
if (flags & AVC_STRICT)
return -EACCES;
 
-   if (is_enforcing(_state) &&
+   if (enforcing_enabled(_state) &&
!(avd->flags & AVD_FLAGS_PERMISSIVE))
return -EACCES;
 
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index d78f9e2f6df0..337fb325e5cc 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5407,7 +5407,7 @@ static int selinux_nlmsg_perm(struct sock *sk, struct 
sk_buff *skb)
   sk->sk_protocol, nlh->nlmsg_type,
   secclass_map[sksec->sclass - 1].name,
   task_pid_nr(current), current->comm);
-   if (!is_enforcing(_state) ||
+   if (!enforcing_enabled(_state) ||
security_get_allow_unknown(_state))
err = 0;
}
@@ -6937,7 +6937,7 @@ static __init int selinux_init(void)
printk(KERN_INFO "SELinux:  Initializing.\n");
 
memset(_state, 0, sizeof(selinux_state));
-   set_enforcing(_state, selinux_enforcing_boot);
+   enforcing_set(_state, selinux_enforcing_boot);
selinux_state.checkreqprot = selinux_checkreqprot_boot;
selinux_ss_init(_state.ss);
 
diff --git a/security/selinux/include/security.h 
b/security/selinux/include/security.h
index c3a1ef10e710..f1db09a5f521 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -111,22 +111,22 @@ void selinux_ss_init(struct selinux_ss **ss);
 extern struct selinux_state selinux_state;
 
 #ifdef CONFIG_SECURITY_SELINUX_DEVELOP
-static inline bool is_enforcing(struct selinux_state *state)
+static inline bool enforcing_enabled(struct selinux_state *state)
 {
return state->enforcing;
 }
 
-static inline void set_enforcing(struct selinux_state *state, bool value)
+static inline void enforcing_set(struct selinux_state *state, bool value)
 {
state->enforcing = value;
 }
 #else
-static inline bool is_enforcing(struct selinux_state *state)
+static inline bool enforcing_enabled(struct selinux_state *state)
 {
return true;
 }
 
-static inline void set_enforcing(struct selinux_state *state, bool value)
+static inline void enforcing_set(struct selinux_state *state, bool value)
 {
 }
 #endif
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 98492755adbf..0dbd5fd6a396 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -98,7 +98,7 @@ static ssize_t sel_read_enforce(struct file *filp, char 
__user *buf,
ssize_t length;
 
length = scnprintf(tmpbuf, TMPBUFLEN, "%d",
-  is_enforcing(_state));
+  enforcing_enabled(_state));
return simple_read_from_buffer(buf, count, ppos, tmpbuf, length);
 }
 
@@ -128,7 +128,7 @@ static ssize_t sel_write_enforce(struct file *file, const 
char __user *buf,
 
new_value = !!new_value;
 
-   old_value = is_enforcing(_state);
+   old_value = enforcing_enabled(_state);
 
if (new_value != old_value) {
length = avc_has_perm(current_sid(), SECINITSID_SECURITY,
@@ -141,7 +141,7 @@ static ssize_t sel_write_enforce(struct file *file, const 
char __user *buf,
new_value, old_value,
from_kuid(_user_ns, audit_get_loginuid(current)),
audit_get_sessionid(current));
-   set_enforcing(_state, new_value);
+   enforcing_set(_state, new_value);
if (new_value)
avc_ss_reset(0);
selnl_notify_setenforce(new_value);
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 3698352213d7..4785ca552d51 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -752,7 +752,7 @@ static int security_validtrans_handle_fail(struct 
selinux_state *state,
kfree(n);
kfree(t);
 
-   if (!is_enforcing(state))
+   if (!enforcing_enabled(state))
return 0;
return -EPERM;
 }
@@ -1596,7 +1596,7 @@ static int compute_sid_handle_invalid_context(
   

Re: [PATCH] selinux: wrap global selinux state

[Paul Moore]

On Fri, Feb 16, 2018 at 12:19 PM, Stephen Smalley  wrote:
> Define a selinux state structure (struct selinux_state) for
> global SELinux state and pass it explicitly to all security server
> functions.  The public portion of the structure contains state
> that is used throughout the SELinux code, such as the enforcing mode.
> The structure also contains a pointer to a selinux_ss structure whose
> definition is private to the security server and contains security
> server specific state such as the policy database and SID table.
>
> This change should have no effect on SELinux behavior or APIs
> (userspace or LSM).  It merely wraps SELinux state and passes it
> explicitly as needed.
>
> Signed-off-by: Stephen Smalley 
> ---
> This is effectively v2 of "selinux: introduce a selinux namespace",
> but rewritten per the review to only perform the encapsulation of state
> and rebased onto latest selinux/next, currently v4.16-rc1-based.
> Changes from v1:
> - Rename selinux_ns to selinux_state,
> - Statically allocate selinux_state and selinux_ss,
> - Drop any namespace-specific fields, code, and references,
> - Use static inlines rather than macros.
>
> I also intend to rework the "selinux: support multiple selinuxfs instances"
> and "selinux: move the AVC into the selinux namespace" patches similarly
> and re-base on this one, but want to wait until this one is finalized since
> every change to this own will require further reworking of the later ones.

Thanks for the respin Stephen, I know that was probably a bit painful
given the size of the patch; it definitely wasn't fun to review.  For
the most part I think everything here looks fine (minor nitpick, see
below), and because of these points:

1) Everything here is internal to SELinux so we change it without
breaking userspace or even other parts of the kernel.

2) Other work is dependent on this patch.

3) A patch of this size and scopr, I want it in linux-next sooner
rather than later.

... I'm going to merge this now, or rather as soon as my test kernel
finishes building and I can give this a quick sanity check.

As expected, there were some minor merge problems with the SCTP
patches, but those were trivially fixed.

> diff --git a/security/selinux/include/security.h 
> b/security/selinux/include/security.h
> index 02f0412d42f2..c3a1ef10e710 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h

...

> +static inline bool is_enforcing(struct selinux_state *state)
> +static inline void set_enforcing(struct selinux_state *state, bool value)

More nitpickery: I'm not a fan of these names.

I'm going to take partial blame for this as I didn't pay close enough
attention to the names earlier, I was focused on the #define vs inline
function nature of the functions.  I realize it's late, and I want to
get this merged (see above), so I'll put together a separate patch on
top of this to change the names.

-- 
paul moore
www.paul-moore.com

Re: Regression found when running LTP connect01 on next-20180301

[Paul Moore]

On Thu, Mar 1, 2018 at 3:01 PM, Anders Roxell <anders.rox...@linaro.org> wrote:
> On 1 March 2018 at 14:42, Paul Moore <p...@paul-moore.com> wrote:
>> On Thu, Mar 1, 2018 at 3:33 AM, Anders Roxell <anders.rox...@linaro.org> 
>> wrote:
>>> Hi,
>>>
>>> I was running LTP's testcase connect01 [1] and found a regression in 
>>> linux-next
>>> (next-20180301).  Bisect gave me this patch as the problematic patch (sha
>>> d452930fd3b9 "selinux: Add SCTP support") on a x86 target.
>>>
>>> Output from the test(LTP release 20180118):
>>> $ cd /opt/ltp/
>>> $ cat runtest/syscalls |grep connect01>runtest/connect-syscall
>>> $ ./runltp -pq -f connect-syscall
>>> "
>>> Running tests...
>>> connect011  TPASS  :  bad file descriptor successful
>>> connect012  TPASS  :  invalid socket buffer successful
>>> connect013  TPASS  :  invalid salen successful
>>> connect014  TPASS  :  invalid socket successful
>>> connect015  TPASS  :  already connected successful
>>> connect016  TPASS  :  connection refused successful
>>> connect017  TFAIL  :  connect01.c:146: invalid address family ; 
>>> returned -1 (expected -1), errno 22 (expected 97)
>>> INFO: ltp-pan reported some tests FAIL
>>> LTP Version: 20180118
>>> "
>>>
>>> The output from the test expected 97 and we received 22, can you please
>>> elaborate on what have been changed?
>>>
>>> Cheers,
>>> Anders
>>> [1] 
>>> https://github.com/linux-test-project/ltp/blob/20180118/testcases/kernel/syscalls/connect/connect01.c#L146
>>
>> Hi Anders,
>>
>> Thanks for the report.  Out of curiosity, we're you running the full
>> LTP test suite and this was the only failure, or did you just run the
>> connect01 test?
>
> Normally we run all syscalls, but when we saw this regression I did the
> bisect and only ran test connect01.
> On every new push we ran 19 different sets of LTP tests, where
> connect01 is part of the syscalls test set.

So this means that only the connect01 test experienced failures?

>>  Either answer is fine, I'm just trying to understand
>> the scope of the regression.
>>
>> Richard, are you able to look into this?  If not, let me know and I'll
>> dig a bit deeper (I'll likely take a quick look today, but if the
>> failure is subtle it might require some digging).
>>
>> --
>> paul moore
>> www.paul-moore.com

-- 
paul moore
www.paul-moore.com

Re: Regression found when running LTP connect01 on next-20180301

[Anders Roxell]

On 1 March 2018 at 14:42, Paul Moore <p...@paul-moore.com> wrote:
> On Thu, Mar 1, 2018 at 3:33 AM, Anders Roxell <anders.rox...@linaro.org> 
> wrote:
>> Hi,
>>
>> I was running LTP's testcase connect01 [1] and found a regression in 
>> linux-next
>> (next-20180301).  Bisect gave me this patch as the problematic patch (sha
>> d452930fd3b9 "selinux: Add SCTP support") on a x86 target.
>>
>> Output from the test(LTP release 20180118):
>> $ cd /opt/ltp/
>> $ cat runtest/syscalls |grep connect01>runtest/connect-syscall
>> $ ./runltp -pq -f connect-syscall
>> "
>> Running tests...
>> connect011  TPASS  :  bad file descriptor successful
>> connect012  TPASS  :  invalid socket buffer successful
>> connect013  TPASS  :  invalid salen successful
>> connect014  TPASS  :  invalid socket successful
>> connect015  TPASS  :  already connected successful
>> connect016  TPASS  :  connection refused successful
>> connect017  TFAIL  :  connect01.c:146: invalid address family ; returned 
>> -1 (expected -1), errno 22 (expected 97)
>> INFO: ltp-pan reported some tests FAIL
>> LTP Version: 20180118
>> "
>>
>> The output from the test expected 97 and we received 22, can you please
>> elaborate on what have been changed?
>>
>> Cheers,
>> Anders
>> [1] 
>> https://github.com/linux-test-project/ltp/blob/20180118/testcases/kernel/syscalls/connect/connect01.c#L146
>
> Hi Anders,
>
> Thanks for the report.  Out of curiosity, we're you running the full
> LTP test suite and this was the only failure, or did you just run the
> connect01 test?

Normally we run all syscalls, but when we saw this regression I did the
bisect and only ran test connect01.
On every new push we ran 19 different sets of LTP tests, where
connect01 is part of the syscalls test set.

Cheers,
Anders

>  Either answer is fine, I'm just trying to understand
> the scope of the regression.
>
> Richard, are you able to look into this?  If not, let me know and I'll
> dig a bit deeper (I'll likely take a quick look today, but if the
> failure is subtle it might require some digging).
>
> --
> paul moore
> www.paul-moore.com

Re: Regression found when running LTP connect01 on next-20180301

[Paul Moore]

On Thu, Mar 1, 2018 at 9:36 AM, Richard Haines
<richard_c_hai...@btinternet.com> wrote:
> On Thu, 2018-03-01 at 08:42 -0500, Paul Moore wrote:
>> On Thu, Mar 1, 2018 at 3:33 AM, Anders Roxell <anders.roxell@linaro.o
>> rg> wrote:
>> > Hi,
>> >
>> > I was running LTP's testcase connect01 [1] and found a regression
>> > in linux-next
>> > (next-20180301).  Bisect gave me this patch as the problematic
>> > patch (sha
>> > d452930fd3b9 "selinux: Add SCTP support") on a x86 target.
>> >
>> > Output from the test(LTP release 20180118):
>> > $ cd /opt/ltp/
>> > $ cat runtest/syscalls |grep connect01>runtest/connect-syscall
>> > $ ./runltp -pq -f connect-syscall
>> > "
>> > Running tests...
>> > connect011  TPASS  :  bad file descriptor successful
>> > connect012  TPASS  :  invalid socket buffer successful
>> > connect013  TPASS  :  invalid salen successful
>> > connect014  TPASS  :  invalid socket successful
>> > connect015  TPASS  :  already connected successful
>> > connect016  TPASS  :  connection refused successful
>> > connect017  TFAIL  :  connect01.c:146: invalid address family ;
>> > returned -1 (expected -1), errno 22 (expected 97)
>> > INFO: ltp-pan reported some tests FAIL
>> > LTP Version: 20180118
>> > "
>> >
>> > The output from the test expected 97 and we received 22, can you
>> > please
>> > elaborate on what have been changed?
>> >
>> > Cheers,
>> > Anders
>> > [1] https://github.com/linux-test-project/ltp/blob/20180118/testcas
>> > es/kernel/syscalls/connect/connect01.c#L146
>>
>> Hi Anders,
>>
>> Thanks for the report.  Out of curiosity, we're you running the full
>> LTP test suite and this was the only failure, or did you just run the
>> connect01 test?  Either answer is fine, I'm just trying to understand
>> the scope of the regression.
>>
>> Richard, are you able to look into this?  If not, let me know and
>> I'll
>> dig a bit deeper (I'll likely take a quick look today, but if the
>> failure is subtle it might require some digging).
>
> I'll have a look today.

Thanks.  Let me know if you get stuck.

-- 
paul moore
www.paul-moore.com

Re: [PATCH] gui/fcontextPage: Set default object class in addDialog

[Stephen Smalley]

On 03/01/2018 06:03 AM, Vit Mojzis wrote:
> This ensures that user cannot leave the object class selection blank.

Thanks, applied both your previous gui/semanagePage patch and this one.

> 
> Signed-off-by: Vit Mojzis 
> ---
>  gui/fcontextPage.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gui/fcontextPage.py b/gui/fcontextPage.py
> index a6577ef7..370bbee4 100644
> --- a/gui/fcontextPage.py
> +++ b/gui/fcontextPage.py
> @@ -164,6 +164,7 @@ class fcontextPage(semanagePage):
>  self.fcontextEntry.set_text("")
>  self.fcontextEntry.set_sensitive(True)
>  self.fcontextFileTypeCombo.set_sensitive(True)
> +self.fcontextFileTypeCombo.set_active(0)
>  self.fcontextTypeEntry.set_text("")
>  self.fcontextMLSEntry.set_text("s0")
>  
> 

Re: [PATCH 3/3] libsemanage: replace access() checks to make setuid programs work

[Stephen Smalley]

On 03/01/2018 09:40 AM, Stephen Smalley wrote:
> On 02/28/2018 03:53 PM, Stephen Smalley wrote:
>> On 02/28/2018 02:44 PM, William Roberts wrote:
>>> On Wed, Feb 28, 2018 at 11:39 AM, Stephen Smalley  
>>> wrote:
 On 02/28/2018 02:26 PM, William Roberts wrote:
> So peeking through the code base, I see:
>
> int semanage_direct_is_managed(semanage_handle_t * sh)
> {
> if (semanage_check_init(sh, sh->conf->store_root_path))
> goto err;
>
> if (semanage_access_check(sh) < 0)
> return 0;
>
> return 1;
>
>   err:
> ERR(sh, "could not check whether policy is managed");
> return STATUS_ERR;
> }
>
> Which semanage_access_check eventually gets down to a raw access check.
>
> Which is only ever used in test_fcontext
>
> semanage_access_check is also the only consumer of 
> semanage_direct_access_check
>
> which is the semanage_store_access_check is only consumed by the
> former and test case and
> the same could be said for semanage_store_access_check
>
> I think this is a good time to roll in patch 4 and drop everything
> relying on semanage_store_access_check.
>
> Thoughts?

 semanage_access_check() is part of the shared library ABI. Can't be
 removed.  Used by seobject.py via the python bindings.  At most, we can
 kill all internal users but the ABI has to remain.
>>>
>>> Ahh yes, duh.
>>>
>>> Outside of just killing off internal users of it, should we modify it
>>> to not use access?
>>> So it at least works under setuid?
>>
>> I don't think it is worthwhile, and it isn't clear how one would test
>> the directory writability case.  Plus semanage_access_check() is only
>> advisory and the caller is free to ignore the result or not call it in
>> the first place.  It is really only intended to allow a program to save
>> itself some work if it isn't going to be able to access the policy store
>> at all, not as a security feature.  Also, as I've said before, I
>> wouldn't warrant libsemanage to be safe if called from a setuid program;
>> no one has ever audited it for such to my knowledge.
> 
> By the way, please test that these patches do not end up yielding silent
> failures or confusing error messages when users run semanage or semodule
> commands with insufficient permissions, e.g. semanage login -l or
> semodule -l as non-root.  That's what semanage_access_check() was for,
> to check up front and provide a useful error message before doing any
> other work.

And for comparison, this is what we get today before these patches:
$ semanage login -l
ValueError: SELinux policy is not managed or store cannot be accessed.

$ semodule -l
libsemanage.semanage_create_store: Could not access module store at
/var/lib/selinux/targeted, or it is not a directory. (Permission denied).
libsemanage.semanage_direct_connect: could not establish direct
connection (Permission denied).
semodule:  Could not connect to policy handler

The messages don't have to be the same, but we need to make sure we have
some useful diagnostic that points to the underlying problem.

Re: [PATCH 3/3] libsemanage: replace access() checks to make setuid programs work

[Stephen Smalley]

On 02/28/2018 03:53 PM, Stephen Smalley wrote:
> On 02/28/2018 02:44 PM, William Roberts wrote:
>> On Wed, Feb 28, 2018 at 11:39 AM, Stephen Smalley  wrote:
>>> On 02/28/2018 02:26 PM, William Roberts wrote:
 So peeking through the code base, I see:

 int semanage_direct_is_managed(semanage_handle_t * sh)
 {
 if (semanage_check_init(sh, sh->conf->store_root_path))
 goto err;

 if (semanage_access_check(sh) < 0)
 return 0;

 return 1;

   err:
 ERR(sh, "could not check whether policy is managed");
 return STATUS_ERR;
 }

 Which semanage_access_check eventually gets down to a raw access check.

 Which is only ever used in test_fcontext

 semanage_access_check is also the only consumer of 
 semanage_direct_access_check

 which is the semanage_store_access_check is only consumed by the
 former and test case and
 the same could be said for semanage_store_access_check

 I think this is a good time to roll in patch 4 and drop everything
 relying on semanage_store_access_check.

 Thoughts?
>>>
>>> semanage_access_check() is part of the shared library ABI. Can't be
>>> removed.  Used by seobject.py via the python bindings.  At most, we can
>>> kill all internal users but the ABI has to remain.
>>
>> Ahh yes, duh.
>>
>> Outside of just killing off internal users of it, should we modify it
>> to not use access?
>> So it at least works under setuid?
> 
> I don't think it is worthwhile, and it isn't clear how one would test
> the directory writability case.  Plus semanage_access_check() is only
> advisory and the caller is free to ignore the result or not call it in
> the first place.  It is really only intended to allow a program to save
> itself some work if it isn't going to be able to access the policy store
> at all, not as a security feature.  Also, as I've said before, I
> wouldn't warrant libsemanage to be safe if called from a setuid program;
> no one has ever audited it for such to my knowledge.

By the way, please test that these patches do not end up yielding silent
failures or confusing error messages when users run semanage or semodule
commands with insufficient permissions, e.g. semanage login -l or
semodule -l as non-root.  That's what semanage_access_check() was for,
to check up front and provide a useful error message before doing any
other work.

Re: Regression found when running LTP connect01 on next-20180301

[Richard Haines via Selinux]

On Thu, 2018-03-01 at 08:42 -0500, Paul Moore wrote:
> On Thu, Mar 1, 2018 at 3:33 AM, Anders Roxell <anders.roxell@linaro.o
> rg> wrote:
> > Hi,
> > 
> > I was running LTP's testcase connect01 [1] and found a regression
> > in linux-next
> > (next-20180301).  Bisect gave me this patch as the problematic
> > patch (sha
> > d452930fd3b9 "selinux: Add SCTP support") on a x86 target.
> > 
> > Output from the test(LTP release 20180118):
> > $ cd /opt/ltp/
> > $ cat runtest/syscalls |grep connect01>runtest/connect-syscall
> > $ ./runltp -pq -f connect-syscall
> > "
> > Running tests...
> > connect011  TPASS  :  bad file descriptor successful
> > connect012  TPASS  :  invalid socket buffer successful
> > connect013  TPASS  :  invalid salen successful
> > connect014  TPASS  :  invalid socket successful
> > connect015  TPASS  :  already connected successful
> > connect016  TPASS  :  connection refused successful
> > connect017  TFAIL  :  connect01.c:146: invalid address family ;
> > returned -1 (expected -1), errno 22 (expected 97)
> > INFO: ltp-pan reported some tests FAIL
> > LTP Version: 20180118
> > "
> > 
> > The output from the test expected 97 and we received 22, can you
> > please
> > elaborate on what have been changed?
> > 
> > Cheers,
> > Anders
> > [1] https://github.com/linux-test-project/ltp/blob/20180118/testcas
> > es/kernel/syscalls/connect/connect01.c#L146
> 
> Hi Anders,
> 
> Thanks for the report.  Out of curiosity, we're you running the full
> LTP test suite and this was the only failure, or did you just run the
> connect01 test?  Either answer is fine, I'm just trying to understand
> the scope of the regression.
> 
> Richard, are you able to look into this?  If not, let me know and
> I'll
> dig a bit deeper (I'll likely take a quick look today, but if the
> failure is subtle it might require some digging).

I'll have a look today.
> 

Re: Regression found when running LTP connect01 on next-20180301

[Paul Moore]

On Thu, Mar 1, 2018 at 3:33 AM, Anders Roxell <anders.rox...@linaro.org> wrote:
> Hi,
>
> I was running LTP's testcase connect01 [1] and found a regression in 
> linux-next
> (next-20180301).  Bisect gave me this patch as the problematic patch (sha
> d452930fd3b9 "selinux: Add SCTP support") on a x86 target.
>
> Output from the test(LTP release 20180118):
> $ cd /opt/ltp/
> $ cat runtest/syscalls |grep connect01>runtest/connect-syscall
> $ ./runltp -pq -f connect-syscall
> "
> Running tests...
> connect011  TPASS  :  bad file descriptor successful
> connect012  TPASS  :  invalid socket buffer successful
> connect013  TPASS  :  invalid salen successful
> connect014  TPASS  :  invalid socket successful
> connect015  TPASS  :  already connected successful
> connect016  TPASS  :  connection refused successful
> connect017  TFAIL  :  connect01.c:146: invalid address family ; returned 
> -1 (expected -1), errno 22 (expected 97)
> INFO: ltp-pan reported some tests FAIL
> LTP Version: 20180118
> "
>
> The output from the test expected 97 and we received 22, can you please
> elaborate on what have been changed?
>
> Cheers,
> Anders
> [1] 
> https://github.com/linux-test-project/ltp/blob/20180118/testcases/kernel/syscalls/connect/connect01.c#L146

Hi Anders,

Thanks for the report.  Out of curiosity, we're you running the full
LTP test suite and this was the only failure, or did you just run the
connect01 test?  Either answer is fine, I'm just trying to understand
the scope of the regression.

Richard, are you able to look into this?  If not, let me know and I'll
dig a bit deeper (I'll likely take a quick look today, but if the
failure is subtle it might require some digging).

-- 
paul moore
www.paul-moore.com

Regression found when running LTP connect01 on next-20180301

[Anders Roxell]

Hi,

I was running LTP's testcase connect01 [1] and found a regression in linux-next
(next-20180301).  Bisect gave me this patch as the problematic patch (sha
d452930fd3b9 "selinux: Add SCTP support") on a x86 target.

Output from the test(LTP release 20180118):
$ cd /opt/ltp/
$ cat runtest/syscalls |grep connect01>runtest/connect-syscall
$ ./runltp -pq -f connect-syscall
"
Running tests...
connect011  TPASS  :  bad file descriptor successful
connect012  TPASS  :  invalid socket buffer successful
connect013  TPASS  :  invalid salen successful
connect014  TPASS  :  invalid socket successful
connect015  TPASS  :  already connected successful
connect016  TPASS  :  connection refused successful
connect017  TFAIL  :  connect01.c:146: invalid address family ; returned -1 
(expected -1), errno 22 (expected 97)
INFO: ltp-pan reported some tests FAIL
LTP Version: 20180118
"

The output from the test expected 97 and we received 22, can you please
elaborate on what have been changed?


Cheers,
Anders
[1] 
https://github.com/linux-test-project/ltp/blob/20180118/testcases/kernel/syscalls/connect/connect01.c#L146

Re: [PATCH 1/3] secilc: Fix documentation build for OS X systems

[Vit Mojzis]

Sorry, wrong patch, please ignore this.


On 1.3.2018 11:59, Vit Mojzis wrote:

From: Yuli Khodorkovskiy 

Since Darwin systems do not have GNU sed installed, the Darwin sed is
missing the "regexp-extended" flag needed to modify the secilc markdown
files before processing with pandoc.

A quick fix for Mac users is to `brew install gnu-sed` and to use gsed.

Signed-off-by: Yuli Khodorkovskiy 
---
  secilc/docs/Makefile | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/secilc/docs/Makefile b/secilc/docs/Makefile
index c0fa6b7f..6b07ce7f 100644
--- a/secilc/docs/Makefile
+++ b/secilc/docs/Makefile
@@ -31,6 +31,12 @@ PANDOC_FILE_LIST = $(addprefix $(TMPDIR)/,$(FILE_LIST))
  PDF_OUT=CIL_Reference_Guide.pdf
  HTML_OUT=CIL_Reference_Guide.html
  PANDOC = pandoc
+SED ?= sed
+
+OS := $(shell uname)
+ifeq ($(OS), Darwin)
+   SED := gsed
+endif
  
  all: html pdf
  
@@ -40,12 +46,12 @@ $(TMPDIR):

  $(TMPDIR)/%.md: %.md | $(TMPDIR)
cp -f $< $(TMPDIR)/
@# Substitute markdown links for conversion into PDF links
-   sed -i -re 's:(\[`[^`]*`\])\([^#]*([^\)]):\1\(\2:g' $@
+   $(SED) -i -re 's:(\[`[^`]*`\])\([^#]*([^\)]):\1\(\2:g' $@
  
  $(TMPDIR)/policy.cil: $(TESTDIR)/policy.cil

cp -f $< $@
@# add a title for the TOC to policy.cil. This is needed to play nicely 
with the PDF conversion.
-   sed -i '1i Example Policy\n=\n```' $@
+   $(SED) -i '1i Example Policy\n=\n```' $@
echo '```' >> $@
  
  html: $(PANDOC_FILE_LIST) $(TMPDIR)/policy.cil

[PATCH] gui/fcontextPage: Set default object class in addDialog

[Vit Mojzis]

This ensures that user cannot leave the object class selection blank.

Signed-off-by: Vit Mojzis 
---
 gui/fcontextPage.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gui/fcontextPage.py b/gui/fcontextPage.py
index a6577ef7..370bbee4 100644
--- a/gui/fcontextPage.py
+++ b/gui/fcontextPage.py
@@ -164,6 +164,7 @@ class fcontextPage(semanagePage):
 self.fcontextEntry.set_text("")
 self.fcontextEntry.set_sensitive(True)
 self.fcontextFileTypeCombo.set_sensitive(True)
+self.fcontextFileTypeCombo.set_active(0)
 self.fcontextTypeEntry.set_text("")
 self.fcontextMLSEntry.set_text("s0")
 
-- 
2.14.3

Re: [PATCH] gui/semanagePage: Close "edit" and "add" dialogues when successfull

[Vit Mojzis]

The traceback was caused by leaving the object class combo box blank (therefore 
is not directly connected to this patch).
But I agree that is's undesirable behavior. I can either add a check that would 
notify the user that they left the option blank, or set a default value.

[PATCH 1/3] secilc: Fix documentation build for OS X systems

[Vit Mojzis]

From: Yuli Khodorkovskiy 

Since Darwin systems do not have GNU sed installed, the Darwin sed is
missing the "regexp-extended" flag needed to modify the secilc markdown
files before processing with pandoc.

A quick fix for Mac users is to `brew install gnu-sed` and to use gsed.

Signed-off-by: Yuli Khodorkovskiy 
---
 secilc/docs/Makefile | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/secilc/docs/Makefile b/secilc/docs/Makefile
index c0fa6b7f..6b07ce7f 100644
--- a/secilc/docs/Makefile
+++ b/secilc/docs/Makefile
@@ -31,6 +31,12 @@ PANDOC_FILE_LIST = $(addprefix $(TMPDIR)/,$(FILE_LIST))
 PDF_OUT=CIL_Reference_Guide.pdf
 HTML_OUT=CIL_Reference_Guide.html
 PANDOC = pandoc
+SED ?= sed
+
+OS := $(shell uname)
+ifeq ($(OS), Darwin)
+   SED := gsed
+endif
 
 all: html pdf
 
@@ -40,12 +46,12 @@ $(TMPDIR):
 $(TMPDIR)/%.md: %.md | $(TMPDIR)
cp -f $< $(TMPDIR)/
@# Substitute markdown links for conversion into PDF links
-   sed -i -re 's:(\[`[^`]*`\])\([^#]*([^\)]):\1\(\2:g' $@
+   $(SED) -i -re 's:(\[`[^`]*`\])\([^#]*([^\)]):\1\(\2:g' $@
 
 $(TMPDIR)/policy.cil: $(TESTDIR)/policy.cil
cp -f $< $@
@# add a title for the TOC to policy.cil. This is needed to play nicely 
with the PDF conversion.
-   sed -i '1i Example Policy\n=\n```' $@
+   $(SED) -i '1i Example Policy\n=\n```' $@
echo '```' >> $@
 
 html: $(PANDOC_FILE_LIST) $(TMPDIR)/policy.cil
-- 
2.14.3