Re: MLS dominance check behavior on el7

2018-09-11 Thread Joshua Brindle 
On Tue, Sep 11, 2018 at 1:33 PM, Stephen Smalley  wrote:
> On 09/11/2018 12:53 PM, Joshua Brindle wrote:
>>
>> On Tue, Sep 11, 2018 at 10:41 AM, Stephen Smalley 
>> wrote:
>>>
>>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>>>
>>>>
>>>> mcstrans mcscolor.c also uses the same logic I'd been using to check
>>>> dominance so this too will no longer function as expected on el7. Do you
>>>> any
>>>> suggestions for doing a 'generic' (one not tied to a specific resource
>>>> class) dominance check in lieu of context contains?
>>>
>>>
>>>
>>> You should probably define your own permission with its own constraint to
>>> avoid depending on the base policy's particular constraint definitions.
>>> Certainly for your own code.  For mcstrans, mcscolor probably ought to be
>>> switched to using at least a separate permission in the context class if
>>> not
>>> its own class to avoid overloading the meaning with pam_selinux's usage
>>> (or
>>> vice versa, but likely harder to change pam_selinux at this point).
>>>
>>
>> Isn't the actual question what the GLB of the 2 contexts is, rather
>> than what permissions one has on the other? It seems like a hack to
>> use permissions to figure out dominance.
>>
>> Would a libselinux interface to determine glb and lub of 2 contexts
>> make sense? Or maybe add a default_range glb and lub option and then
>> calculate it using relabel?
>
>
> At least as used in mcstrans, it appears to be a way of matching which entry
> from the colors configuration to use.  So it is just a "Can context C1 use
> the colors specified for context C2?" question.  It just happens that the
> way they are deciding that for the MLS part is through the dominance
> relation.  And determining whether context C1 dominates context C2 is
> something only the kernel security server or libsepol with the same policy
> file loaded into it can answer, not libselinux or anything else.
>

I meant an libselinux as in a library interface to some file in
selinuxfs to calculate the glb.

If it is 'permission to see a color' that makes sense, I was thinking
the source context and target context have a glb that maps to the
color to be shown.
___
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: MLS dominance check behavior on el7

2018-09-11 Thread Joshua Brindle 
On Tue, Sep 11, 2018 at 10:41 AM, Stephen Smalley  wrote:
> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>
>> mcstrans mcscolor.c also uses the same logic I'd been using to check
>> dominance so this too will no longer function as expected on el7. Do you any
>> suggestions for doing a 'generic' (one not tied to a specific resource
>> class) dominance check in lieu of context contains?
>
>
> You should probably define your own permission with its own constraint to
> avoid depending on the base policy's particular constraint definitions.
> Certainly for your own code.  For mcstrans, mcscolor probably ought to be
> switched to using at least a separate permission in the context class if not
> its own class to avoid overloading the meaning with pam_selinux's usage (or
> vice versa, but likely harder to change pam_selinux at this point).
>

Isn't the actual question what the GLB of the 2 contexts is, rather
than what permissions one has on the other? It seems like a hack to
use permissions to figure out dominance.

Would a libselinux interface to determine glb and lub of 2 contexts
make sense? Or maybe add a default_range glb and lub option and then
calculate it using relabel?
___
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: A casestudy where selinux has stopped malware attacks

2017-09-21 Thread Joshua Brindle 

masoom alam wrote:

Hi every one,

Do we have some thing like the mentioned subject documented?

Thank you.



Probably one of the better catalogued set of malware stopped by SELinux, 
which shows various ways SELinux mitigated the attacks, is The Case For 
SEAndroid from Stephen Smalley:


https://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf

Re: Announcing SPAN: SELinux Policy Analysis Notebook

2017-05-09 Thread Joshua Brindle 

Karl MacMillan wrote:




5. any references to type attributes should be customizable: ie. process_types 
= ... filesystem_types = ... etc

I do not consider Linux access vectors to be customizable, unlike types 
,attributes, booleans, tunables etc)



I know what you mean, but I have to point out that the domain attribute has 
been much more stable across many different operating systems than the object 
classes and access vectors.


This is true, and being able to specify subject types and object types 
(processes and files are instances of those) could make this useful for 
analysis of e.g., Xen policies... Not that I see a huge demand for that 
sort of thing

Re: Announcing SPAN: SELinux Policy Analysis Notebook

2017-05-07 Thread Joshua Brindle 

Dominick Grift wrote:

On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the

Dominick Grift wrote:



The idea is nice, unfortunately its inflexible and it has hard-references to 
reference policy all-over. It has potential but it is still rough.


Of course, it is an analysis of a refpolicy-based policy. If you want to
analyze a different policy (e.g., Android or home-rolled) you will have to
change out all of the type sets, etc.

You can't make a magic generic analysis script without knowing how key parts
of the system work and what types are associated with those components.


What do you mean? that for example that hard-coded array of "trusted" types. Is 
that not just redundant.



you mean the example trusted types? I'm not sure I understand your concern.


Can't i just create that array myself and use it to exlude rules with types in 
that array? That was one does not have to hard-code it.



It is python, you can do anything you want. The example notebook is a 
starting point, anyone doing an analysis would probably make major 
changes for their analysis, which is the point. You modify the notebook 
to build a usable analysis between the starting policy and the policy 
you are analyzing.


I've thought about trying this on an Android policy but haven't made it 
a priority.



Also with regard to hardcoding the refpolicy file system 
(ps.load_policy_source). I mean if youre just going to `grep -r` then why do we 
have to assume anything there and hard code file suffixed, directory structures 
etc etc?

Re: Announcing SPAN: SELinux Policy Analysis Notebook

2017-05-07 Thread Joshua Brindle 

Dominick Grift wrote:



The idea is nice, unfortunately its inflexible and it has hard-references to 
reference policy all-over. It has potential but it is still rough.



Of course, it is an analysis of a refpolicy-based policy. If you want to 
analyze a different policy (e.g., Android or home-rolled) you will have 
to change out all of the type sets, etc.


You can't make a magic generic analysis script without knowing how key 
parts of the system work and what types are associated with those 
components.

Re: [RFC][PATCH] selinux: add a map permission check for mmap

2017-05-05 Thread Joshua Brindle 

Stephen Smalley wrote:

Add a map permission check on mmap so that we can distinguish memory mapped
access (since it has different implications for revocation). When a file
is opened and then read or written via syscalls like read(2)/write(2),
we revalidate access on each read/write operation via
selinux_file_permission() and therefore can revoke access if the
process context, the file context, or the policy changes in such a
manner that access is no longer allowed. When a file is opened and then
memory mapped via mmap(2) and then subsequently read or written directly
in memory, we presently have no way to revalidate or revoke access.
The purpose of a separate map permission check on mmap(2) is to permit
policy to prohibit memory mapping of specific files for which we need
to ensure that every access is revalidated, particularly useful for
scenarios where we expect the file to be relabeled at runtime in order
to reflect state changes (e.g. cross-domain solution, assured pipeline
without data copying).

Signed-off-by: Stephen Smalley
---
NB I chose not to define a new policy capability for this permission,
since it is adequately covered by handle_unknown for compatibility and
others seemed to agree that this does not fall into the category of
changes requiring a new policy capability.  I also chose to define the
permission for socket classes in addition to file classes and let it
be checked for both.


Thank you. This is very helpful. This fully closes the relabel 
revocation issue, right?


Is it actually safe to tell people that relabel+move is sufficient in an 
assured pipeline now?




  security/selinux/hooks.c| 12 
  security/selinux/include/classmap.h |  2 +-
  2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e67a526..5432628 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3550,6 +3550,18 @@ static int selinux_mmap_addr(unsigned long addr)
  static int selinux_mmap_file(struct file *file, unsigned long reqprot,
 unsigned long prot, unsigned long flags)
  {
+   struct common_audit_data ad;
+   int rc;
+
+   if (file) {
+   ad.type = LSM_AUDIT_DATA_FILE;
+   ad.u.file = file;
+   rc = inode_has_perm(current_cred(), file_inode(file),
+   FILE__MAP,);
+   if (rc)
+   return rc;
+   }
+
if (selinux_checkreqprot)
prot = reqprot;

diff --git a/security/selinux/include/classmap.h 
b/security/selinux/include/classmap.h
index 1e0cc9b..3e49a78 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -1,7 +1,7 @@
  #include

  #define COMMON_FILE_SOCK_PERMS "ioctl", "read", "write", "create", \
-"getattr", "setattr", "lock", "relabelfrom", "relabelto", "append"
+"getattr", "setattr", "lock", "relabelfrom", "relabelto", "append", "map"

  #define COMMON_FILE_PERMS COMMON_FILE_SOCK_PERMS, "unlink", "link", \
  "rename", "execute", "quotaon", "mounton", "audit_access", \

Re: MLS directory label inheritance rules

2017-04-07 Thread Joshua Brindle 

Dennis Sherrell wrote:

In a thread ending with Nick Kravelich's contact infirmation, it was
written:

"
If you write top secret data it should stay top secret even if you're
writing to a folder that is normally reserved for secret data, or perhaps
mixed data. Iirc it uses the MLS of the process when creating the file
entry."

I disagree. Top Secret data shoud not be written to a folder which was not
provisioned for such. Allowing persons or processess of lower
classification access to "containers" with higher clearance requirements
could cause a data spill. Any thoughts as to active handling of such?



These are just the default labeling rules. The reading or writing would 
still need to be allowed by the TE policy and not removed by the 
constraints. MLS constraints should prevent a write from a TS subject to 
a S object regardless of what the default rule says the label should be.



Dennis Sherrell
Sherrell Consulting
Bakersfield, California Company #136601
Counter-Terrorism
Cybernetic Countermeasure Developer

On Fri, Apr 7, 2017, 12:55 PM Stephen Smalley  wrote:


On Fri, 2017-04-07 at 15:41 -0400, Stephen Smalley wrote:

On Fri, 2017-04-07 at 11:39 -0700, Nick Kralevich wrote:

When a file is created in a directory, the default label for the
file
is based on the label of the enclosing directory (unless something
like setfscreatecon is used). For example:

bullhead:/ # cd /data/misc/zoneinfo/

bullhead:/data/misc/zoneinfo # ls -ladZ .
drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096
1971-06-19 17:07 .
bullhead:/data/misc/zoneinfo # touch asdf
bullhead:/data/misc/zoneinfo # ls -ladZ . asdf

drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096
2017-04-07 18:32 .
-rw-rw-rw- 1 root   root   u:object_r:zoneinfo_data_file:s00
2017-04-07 18:32 asdf

note how the label of the "asdf" file matches the label of the
enclosing directory.

However, that's not true when the directory uses categories. In
that
case, the newly created file inherits the label, but not the
categories. For example:

bullhead:/data/data # cd /data/data/com.android.chrome
bullhead:/data/data/com.android.chrome # ls -ladZ .
drwx-- 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768
4096
1971-07-15 15:31 .
bullhead:/data/data/com.android.chrome # touch asdf
bullhead:/data/data/com.android.chrome # ls -laZd . asdf
drwx-- 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768
4096
2017-04-07 18:35 .
-rw-rw-rw- 1
root   root   u:object_r:app_data_file:s0  0
2017-04-07 18:35 asdf

Note how the label is maintained, but the "c512,c768" portion is
not
maintained. While this example occurs when I'm running in a
permissive
domain, it also occurs in an enforcing domain.

The inconsistency seems weird, and I'm sure there's a good reason
why
this occurs that I'm not familiar with. Can someone help me
understand
if this is expected, and if so, why?

First, the good news is that you get to specify which behavior you
want
for each context field and object class through policy (as long as
your
kernel and policy version supports it), see:
https://selinuxproject.org/page/DefaultRules

Second, there are different defaults for each of the fields of the
security contexts based on what is most normative for that particular
security model.  The user identity defaults to that of the creating
process since we typically do not allow a process to create files
with
a different user identity and want the file to reflect its creator
(this is defined through constraints on user identity in policies
that
define more than one, unlike Android). The role defaults to the fixed
object_r role because originally we didn't envision a use case for
roles on files.  The MLS range defaults to the low/current level of
the
process because a process is typically not allowed to create files at
a
different level and we want the file to reflect the sensitivity of
the
data which originated from the process. The type defaults to a
related
object type (in this case that of the parent directory) because
process
domains and object types are separate (aside from overlapping use for
/proc/pid) and the relationships among them are explicit through the
TE
rules / access matrix rather than through implicit rules.

Of course, in addition to being able to globally configure the
default
behavior, you can also customize specific cases through the
role/type/range_transition rules.

With your example above, you wanted the file to inherit the level of
the directory, but consider the situation where a process with
categories (:s0:c512,c768) creates a file in some shared
(mlstrustedobject) directory that is just :s0.  Do you want that file
to end up as just :s0?  In the MLS world, that would be a downgrade /
info leak.

I guess that's not a great example since then the file would also end
up with the same type by default and thus would be a mlstrustedobject
and accessible regardless of its level.  So you'd want a type
transition to a

Re: [RFC] Build ANDROID_HOST=y on mac

2016-09-28 Thread Joshua Brindle 

William Roberts wrote:

On Sep 28, 2016 17:07, "Joshua Brindle"<brin...@quarksecurity.com>  wrote:

William Roberts wrote:

On Sep 28, 2016 16:54, "Joshua Brindle"<brin...@quarksecurity.com>

wrote:

Joshua Brindle wrote:

William Roberts wrote:

   From commit 35d702 on
https://github.com/williamcroberts/selinux/tree/fix-mac

I have a branch that is building on my elcapitan mac, requesting any
comments anyone
wishes to make, before I send them out.

If you wish to test, this is the procedure

1. Build libsepol (assumes at root of tree)
a, cd libsepol
b. make
2. Build libselinux
a. cd libselinux (assumes at root of tree)
b. make ANDROID_HOST=y


This works for me.


make install DESTDIR=/tmp/someidr mostly works, Mac ln does not support

--relative so that fails. ANDROID_HOST also needs to be set in the top
level makefile so that it propagates down:

ANDROID_HOST ?= n


Yeah install doesn't work on Mac, that's why for Darwin we just set the
path to the libsepol location for sefcontext_compile.

As for ANDROID_HOST, why does it need to go higher? It's only used in
libselinux and is declared and used just like DISABLE_SETRANS...I'm not
following you?


Because I was building from the top, basically seeing if I could get a

usable toolchain out of it, but that looks like it would require a bit more
work.

Ahh yeah, that won't work yet, but that would be nice.


I got checkpolicy and checkmodule out. No cilc stuff and dispol/dismod 
needs byteswap.h and endian.h.







This essentially gets us to where a build server/maintainer
can test patches quickly on mac, with some assurance
it's not busted without downloading all of Android.

It's still wise to check in an Android tree if possible IMHO.





___
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: [RFC] Build ANDROID_HOST=y on mac

2016-09-28 Thread Joshua Brindle 

William Roberts wrote:

On Sep 28, 2016 16:54, "Joshua Brindle"<brin...@quarksecurity.com>  wrote:

Joshua Brindle wrote:

William Roberts wrote:

 From commit 35d702 on
https://github.com/williamcroberts/selinux/tree/fix-mac

I have a branch that is building on my elcapitan mac, requesting any
comments anyone
wishes to make, before I send them out.

If you wish to test, this is the procedure

1. Build libsepol (assumes at root of tree)
a, cd libsepol
b. make
2. Build libselinux
a. cd libselinux (assumes at root of tree)
b. make ANDROID_HOST=y


This works for me.


make install DESTDIR=/tmp/someidr mostly works, Mac ln does not support

--relative so that fails. ANDROID_HOST also needs to be set in the top
level makefile so that it propagates down:

ANDROID_HOST ?= n


Yeah install doesn't work on Mac, that's why for Darwin we just set the
path to the libsepol location for sefcontext_compile.

As for ANDROID_HOST, why does it need to go higher? It's only used in
libselinux and is declared and used just like DISABLE_SETRANS...I'm not
following you?



Because I was building from the top, basically seeing if I could get a 
usable toolchain out of it, but that looks like it would require a bit 
more work.







This essentially gets us to where a build server/maintainer
can test patches quickly on mac, with some assurance
it's not busted without downloading all of Android.

It's still wise to check in an Android tree if possible IMHO.





___
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: Libsepol Mac Build Errors

2016-09-23 Thread Joshua Brindle 

William Roberts wrote:

On Fri, Sep 23, 2016 at 6:10 PM, Joshua Brindle
<brin...@quarksecurity.com>  wrote:

william.c.robe...@intel.com wrote:

The patches below fix some warnings reported by Josh Brindle on
the libsepol build.

Josh can you test these and see if those three warning go away
and give an ack if they are ok?

[PATCH 1/3] libsepol: fix unused variable 'size' on mac build
[PATCH 2/3] libsepol: fix unused variable 'len' on mac build
[PATCH 3/3] libsepol: fix unitialized variable 'nread' on mac build


That fixed the build errors. The linker does not like the soname, version
map, etc stuff though so I still don't get a sofile out.


FYI I managed to set up macincloud today, so I have an el capitain instance
with 8 cores and 16GB ram I can use for testing. I'm currently syncing the
source tree, so ill be able to test on mac.


Well that is neat.

FWIW I have an Android tree but I was building your selinux repo outside 
of Android. I personally keep around darwin libsepol.so files built out 
of Android for use with setools 4 since it works on Mac's now so I 
appreciate any work to make it work better on Mac :)

___
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: Libsepol Mac Build Errors

2016-09-23 Thread Joshua Brindle 

william.c.robe...@intel.com wrote:

The patches below fix some warnings reported by Josh Brindle on
the libsepol build.

Josh can you test these and see if those three warning go away
and give an ack if they are ok?

[PATCH 1/3] libsepol: fix unused variable 'size' on mac build
[PATCH 2/3] libsepol: fix unused variable 'len' on mac build
[PATCH 3/3] libsepol: fix unitialized variable 'nread' on mac build


That fixed the build errors. The linker does not like the soname, 
version map, etc stuff though so I still don't get a sofile out.


___
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: Killing The Android libselinux Fork (available)

2016-09-23 Thread Joshua Brindle 

William Roberts wrote:

On Sep 22, 2016 9:18 PM, "Jeffrey Vander Stoep"  wrote:

Remember to test on the Mac build. About a year ago I moved the host side

tools over to upstream libselinux, but had to revert because it broke the
Mac build in multiple places. Since then Richard Haines has done a lot of
work to reduce the diff between upstream and the Android fork. Hopefully
that will reduce your effort.

Yeah I'm quite concerned about the Mac build, does anyone on here have
access to a Mac for testing?


I do, let me know when you have a branch you need looked at and I'll try 
to get to it.






On Thu, Sep 22, 2016 at 6:39 PM William Roberts

wrote:

On Thu, Sep 22, 2016 at 6:34 PM, William Roberts
  wrote:

So I have been working the last couple of days to understand what it
would take to kill external/libselinux (the Android Fork) and fixup
upstream so most of the delta is in. The only thing we would keep on
the Android side, is android.c and .h. Since those files are self
contained, we should just be able to merge upstream without concerns
of conflict. If we really wanted to, we could spin off a separate
libselinux-android that builds those two files and links to
libselinux, but that seems overkill IMHO.

The work is available here:
https://github.com/williamcroberts/selinux/tree/fork-kill

Currently to Build:
1. remove external/libselinux
2. apply this patch to bionic if not present:
https://android-review.googlesource.com/#/c/276918
3. either set external/selinux to my fork-kill branch or merge selinux
upstream master into external/selinux and apply the two patches listed
below:

Patches that matter ( I don't know how to make pretty little git

summaries):

commit e017f48acd2791a6aa62b4ed0c0b44256b26651f
Author: William Roberts
Date:   Wed Sep 21 16:06:37 2016 -0700
libselinux: add The Android fork files

commit f40d7facbcaf1337f37b5630b98806fd25b1dbf9
Author: William Roberts
Date:   Wed Sep 21 16:00:34 2016 -0700
libselinux: rectify the Android fork

The goal would be to upstream commit f40d7facb and leave
commit e017f48ac on the Android tree.

I am going to do some further testing tomorrow, and plan on submitting
the upstream patch f40d7facbc on Monday. If anyone wants to leave
preliminary feedback, or has a specific thing they want tested, let me

know.

Currently tested on the emulator and checked that the digest mechanism

for

last restorecon value is working.

--
Respectfully,

William C Roberts

FYI I may rebase that branch at anytime... you have been warned :-P


___
Seandroid-list mailing list
seandroid-l...@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to 
seandroid-list-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] Correctly detect unknown classes in sepol_string_to_security_class

2016-06-21 Thread Joshua Brindle 

Stephen Smalley wrote:

On 06/03/2016 11:17 AM, Joshua Brindle wrote:

Bail before running off the end of the class index

Change-Id: I47c4eaac3c7d789f8d85047e34e37e3f0bb38b3a
Signed-off-by: Joshua Brindle<brin...@quarksecurity.com>


Applied this one and then rewrote it to use hashtab_search().
Not sure why it wasn't that way in the first place.


Thank you, that was a much better fix that I should have noticed...




---
  libsepol/src/services.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libsepol/src/services.c b/libsepol/src/services.c
index d64a8e8..665fcaa 100644
--- a/libsepol/src/services.c
+++ b/libsepol/src/services.c
@@ -1155,7 +1155,7 @@ int hidden sepol_string_to_security_class(const char 
*class_name,
char *class = NULL;
sepol_security_class_t id;

-   for (id = 1;; id++) {
+   for (id = 1; id<= policydb->p_classes.nprim; id++) {
class = policydb->p_class_val_to_name[id - 1];
if (class == NULL) {
ERR(NULL, "could not convert %s to class id", 
class_name);
@@ -1166,6 +1166,8 @@ int hidden sepol_string_to_security_class(const char 
*class_name,
return STATUS_SUCCESS;
}
}
+   ERR(NULL, "unrecognized class %s", class_name);
+   return -EINVAL;
  }

  /*





___
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] Correctly detect unknown classes in sepol_string_to_security_class

2016-06-03 Thread Joshua Brindle 

Joshua Brindle wrote:

Bail before running off the end of the class index



This one correctly goes all the way to the end of the classes index, the 
last version did not.



Change-Id: I47c4eaac3c7d789f8d85047e34e37e3f0bb38b3a
Signed-off-by: Joshua Brindle<brin...@quarksecurity.com>
---
  libsepol/src/services.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libsepol/src/services.c b/libsepol/src/services.c
index d64a8e8..665fcaa 100644
--- a/libsepol/src/services.c
+++ b/libsepol/src/services.c
@@ -1155,7 +1155,7 @@ int hidden sepol_string_to_security_class(const char 
*class_name,
char *class = NULL;
sepol_security_class_t id;

-   for (id = 1;; id++) {
+   for (id = 1; id<= policydb->p_classes.nprim; id++) {
class = policydb->p_class_val_to_name[id - 1];
if (class == NULL) {
ERR(NULL, "could not convert %s to class id", 
class_name);
@@ -1166,6 +1166,8 @@ int hidden sepol_string_to_security_class(const char 
*class_name,
return STATUS_SUCCESS;
}
}
+   ERR(NULL, "unrecognized class %s", class_name);
+   return -EINVAL;
  }

  /*


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

[PATCH] Correctly detect unknown classes in sepol_string_to_security_class

2016-06-03 Thread Joshua Brindle 
Bail before running off the end of the class index

Change-Id: I47c4eaac3c7d789f8d85047e34e37e3f0bb38b3a
Signed-off-by: Joshua Brindle <brin...@quarksecurity.com>
---
 libsepol/src/services.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libsepol/src/services.c b/libsepol/src/services.c
index d64a8e8..665fcaa 100644
--- a/libsepol/src/services.c
+++ b/libsepol/src/services.c
@@ -1155,7 +1155,7 @@ int hidden sepol_string_to_security_class(const char 
*class_name,
char *class = NULL;
sepol_security_class_t id;
 
-   for (id = 1;; id++) {
+   for (id = 1; id <= policydb->p_classes.nprim; id++) {
class = policydb->p_class_val_to_name[id - 1];
if (class == NULL) {
ERR(NULL, "could not convert %s to class id", 
class_name);
@@ -1166,6 +1166,8 @@ int hidden sepol_string_to_security_class(const char 
*class_name,
return STATUS_SUCCESS;
}
}
+   ERR(NULL, "unrecognized class %s", class_name);
+   return -EINVAL;
 }
 
 /*
-- 
2.1.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.

[PATCH 1/2] Modify audit2why analyze function to use loaded policy

2016-06-03 Thread Joshua Brindle 
Class and perms should come from the policy being used for analysis,
not the system policy so use sepol_ interfaces

Change-Id: Ia0590ed2514249fd98810a8d4fe87f8bf5280561
Signed-off-by: Joshua Brindle <brin...@quarksecurity.com>
---
 libselinux/src/audit2why.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libselinux/src/audit2why.c b/libselinux/src/audit2why.c
index 12745b3..abe1701 100644
--- a/libselinux/src/audit2why.c
+++ b/libselinux/src/audit2why.c
@@ -343,8 +343,8 @@ static PyObject *analyze(PyObject *self 
__attribute__((unused)) , PyObject *args
if (rc < 0)
RETURN(BADTCON)
 
-   tclass = string_to_security_class(tclassstr);
-   if (!tclass)
+   rc = sepol_string_to_security_class(tclassstr, );
+   if (rc < 0)
RETURN(BADTCLASS)
 
/* Convert the permission list to an AV. */
@@ -365,8 +365,8 @@ static PyObject *analyze(PyObject *self 
__attribute__((unused)) , PyObject *args
permstr = PyString_AsString( strObj );
 #endif

-   perm = string_to_av_perm(tclass, permstr);
-   if (!perm)
+   rc = sepol_string_to_av_perm(tclass, permstr, );
+   if (rc < 0)
RETURN(BADPERM)
 
av |= perm;
-- 
2.1.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.

[PATCH 2/2] Correctly detect unknown classes in sepol_string_to_security_class

2016-06-03 Thread Joshua Brindle 
Bail before running off the end of the class index

Change-Id: I47c4eaac3c7d789f8d85047e34e37e3f0bb38b3a
Signed-off-by: Joshua Brindle <brin...@quarksecurity.com>
---
 libsepol/src/services.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libsepol/src/services.c b/libsepol/src/services.c
index d64a8e8..8679545 100644
--- a/libsepol/src/services.c
+++ b/libsepol/src/services.c
@@ -1155,7 +1155,7 @@ int hidden sepol_string_to_security_class(const char 
*class_name,
char *class = NULL;
sepol_security_class_t id;
 
-   for (id = 1;; id++) {
+   for (id = 1; id < policydb->p_classes.nprim; id++) {
class = policydb->p_class_val_to_name[id - 1];
if (class == NULL) {
ERR(NULL, "could not convert %s to class id", 
class_name);
@@ -1166,6 +1166,8 @@ int hidden sepol_string_to_security_class(const char 
*class_name,
return STATUS_SUCCESS;
}
}
+   ERR(NULL, "unrecognized class %s", class_name);
+   return -EINVAL;
 }
 
 /*
-- 
2.1.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.

Re: [PATCH] Modify audit2why analyze function to use loaded policy

2016-06-03 Thread Joshua Brindle 

Joshua Brindle wrote:

Class and perms should come from the policy being used for analysis,
not the system policy so use sepol_ interfaces



Hrm, this solved my original problem which was that I was getting the 
wrong answer back from audit2why (classes in my policy that weren't in 
the system policy can back with BADTCLASS instead of a more appropriate 
answer) but now I have a segfault so I'll try to track that down.



Change-Id: Ia0590ed2514249fd98810a8d4fe87f8bf5280561
---
  libselinux/src/audit2why.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libselinux/src/audit2why.c b/libselinux/src/audit2why.c
index 12745b3..abe1701 100644
--- a/libselinux/src/audit2why.c
+++ b/libselinux/src/audit2why.c
@@ -343,8 +343,8 @@ static PyObject *analyze(PyObject *self 
__attribute__((unused)) , PyObject *args
if (rc<  0)
RETURN(BADTCON)

-   tclass = string_to_security_class(tclassstr);
-   if (!tclass)
+   rc = sepol_string_to_security_class(tclassstr,);
+   if (rc<  0)
RETURN(BADTCLASS)

/* Convert the permission list to an AV. */
@@ -365,8 +365,8 @@ static PyObject *analyze(PyObject *self 
__attribute__((unused)) , PyObject *args
permstr = PyString_AsString( strObj );
  #endif

-   perm = string_to_av_perm(tclass, permstr);
-   if (!perm)
+   rc = sepol_string_to_av_perm(tclass, permstr,);
+   if (rc<  0)
RETURN(BADPERM)

av |= perm;


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

[PATCH] Modify audit2why analyze function to use loaded policy

2016-06-02 Thread Joshua Brindle 
Class and perms should come from the policy being used for analysis,
not the system policy so use sepol_ interfaces

Change-Id: Ia0590ed2514249fd98810a8d4fe87f8bf5280561
---
 libselinux/src/audit2why.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libselinux/src/audit2why.c b/libselinux/src/audit2why.c
index 12745b3..abe1701 100644
--- a/libselinux/src/audit2why.c
+++ b/libselinux/src/audit2why.c
@@ -343,8 +343,8 @@ static PyObject *analyze(PyObject *self 
__attribute__((unused)) , PyObject *args
if (rc < 0)
RETURN(BADTCON)
 
-   tclass = string_to_security_class(tclassstr);
-   if (!tclass)
+   rc = sepol_string_to_security_class(tclassstr, );
+   if (rc < 0)
RETURN(BADTCLASS)
 
/* Convert the permission list to an AV. */
@@ -365,8 +365,8 @@ static PyObject *analyze(PyObject *self 
__attribute__((unused)) , PyObject *args
permstr = PyString_AsString( strObj );
 #endif

-   perm = string_to_av_perm(tclass, permstr);
-   if (!perm)
+   rc = sepol_string_to_av_perm(tclass, permstr, );
+   if (rc < 0)
RETURN(BADPERM)
 
av |= perm;
-- 
2.1.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.

Re: XWindows and CLIP?

2016-06-02 Thread Joshua Brindle 

John Chludzinski wrote:

What are the issues with XWindows and CLIP? Why is CLIP XWindow-less?


CLIP strives to be a minimal system suited to secure solutions and does 
not come with software not necessary for such systems (e.g., cross 
domain solutions).



Is there something inherently unsecure with the XWindow client/server
model?


Xorg manages interactions between programs running under X itself and is 
therefore an object manager (similar to how an RDBMS is an object 
manager that manages rows and tables).


There is work to extend SELinux controls to Xorg (XACE) but without 
using XACE and X SELinux policy you cannot meaningfully manage 
information flow between X applications uses SELinux.


___
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: Build policy on systems not supporting DCCP protocol

2016-04-24 Thread Joshua Brindle 

Richard Haines wrote:

Commit 3895fbbe0cf2ec52d6b6eda66084b6e9f8d88fb2 ("selinux: Add support
for portcon dccp protocol") added support for the (portcon dccp ..)
statement. This fix will allow policy to be built on platforms
(see [1]) that do not have DCCP support by defining the IANA
assigned IP Protocol Number 33 to IPPROTO_DCCP.

[1] https://android-review.googlesource.com/#/c/219568/

Signed-off-by: Richard Haines
---
  checkpolicy/checkpolicy.c | 3 +++
  checkpolicy/policy_define.c   | 3 +++
  libsepol/cil/src/cil_binary.c | 3 +++
  libsepol/src/module_to_cil.c  | 3 +++
  libsepol/src/ports.c  | 3 +++


Seems like this should be in a private header.


  5 files changed, 15 insertions(+)

diff --git a/checkpolicy/checkpolicy.c b/checkpolicy/checkpolicy.c
index ea9ee00..7947c20 100644
--- a/checkpolicy/checkpolicy.c
+++ b/checkpolicy/checkpolicy.c
@@ -64,6 +64,9 @@
  #include
  #include
  #include
+#ifndef IPPROTO_DCCP
+#define IPPROTO_DCCP 33
+#endif
  #include
  #include
  #include
diff --git a/checkpolicy/policy_define.c b/checkpolicy/policy_define.c
index 7a4d2f1..2068b71 100644
--- a/checkpolicy/policy_define.c
+++ b/checkpolicy/policy_define.c
@@ -36,6 +36,9 @@
  #include
  #include
  #include
+#ifndef IPPROTO_DCCP
+#define IPPROTO_DCCP 33
+#endif
  #include
  #include
  #include
diff --git a/libsepol/cil/src/cil_binary.c b/libsepol/cil/src/cil_binary.c
index 8233dfd..b8437c9 100644
--- a/libsepol/cil/src/cil_binary.c
+++ b/libsepol/cil/src/cil_binary.c
@@ -31,6 +31,9 @@
  #include
  #include
  #include
+#ifndef IPPROTO_DCCP
+#define IPPROTO_DCCP 33
+#endif

  #include
  #include
diff --git a/libsepol/src/module_to_cil.c b/libsepol/src/module_to_cil.c
index b478d9f..38f0dc3 100644
--- a/libsepol/src/module_to_cil.c
+++ b/libsepol/src/module_to_cil.c
@@ -26,6 +26,9 @@
  #include
  #include
  #include
+#ifndef IPPROTO_DCCP
+#define IPPROTO_DCCP 33
+#endif
  #include
  #include
  #include
diff --git a/libsepol/src/ports.c b/libsepol/src/ports.c
index b1ee094..62ec602 100644
--- a/libsepol/src/ports.c
+++ b/libsepol/src/ports.c
@@ -1,4 +1,7 @@
  #include
+#ifndef IPPROTO_DCCP
+#define IPPROTO_DCCP 33
+#endif
  #include

  #include "debug.h"


___
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] update deps and change yum to dnf

2016-01-04 Thread Joshua Brindle 

Dominick Grift wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Jan 04, 2016 at 05:30:31PM +0100, Dominick Grift wrote:

On Mon, Jan 04, 2016 at 09:23:54AM -0500, Joshua Brindle wrote:

---
  README | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index dae1eb9..2497485 100644
--- a/README
+++ b/README
@@ -2,7 +2,7 @@ Please submit all bug reports and patches to 
selinux@tycho.nsa.gov.
  Subscribe via selinux-j...@tycho.nsa.gov.

  Build dependencies on Fedora:
-yum install audit-libs-devel bison bzip2-devel dbus-devel dbus-glib-devel flex 
flex-devel flex-static glib2-devel libcap-devel libcap-ng-devel pam-devel 
pcre-devel python-devel setools-devel swig ustr-devel
+dnf install audit-libs-devel bison bzip2-devel dbus-devel dbus-glib-devel flex 
flex-devel flex-static glib2-devel libcap-devel libcap-ng-devel pam-devel 
pcre-devel python-devel setools-devel swig ustr-devel gcc redhat-rpm-config 
xmlto

What are xmlto, and redhat-rpm-config for?


Oh i see it is to build man pages 
(https://github.com/SELinuxProject/selinux/blob/master/secilc/Makefile#L14)

redhat-rpm-config seems only needed if you use rpm to build? If you use
rpm to build then there are probably other requirements as well, and


I encountered this on a fresh F23 system by running DESTDIR=~/tmp make 
install pywrap-install. I was not building with rpm.



then i believe you do not strictly require that package or gcc for that
matter since those are part of the core build tools (1):

  Exceptions

There is no need to include the following packages or their dependencies
as Build Requires because they would occur too often. These packages are
considered the minimum build environment.

bash
bzip2
coreutils
cpio
diffutils
fedora-release (and/or redhat-release)
gcc
gcc-c++
gzip
make
patch
perl
rpm-build
redhat-rpm-config
sed
tar
unzip

(1) https://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires


Building secilc html and pdf docs requires pandoc as per: 
https://github.com/SELinuxProject/selinux/blob/master/secilc/README#L59



  To build and install everything under a private directory, run:
  make DESTDIR=~/obj install install-pywrap
--
2.5.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.

--
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get=0x314883A202DFF788
Dominick Grift


- --
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get=0x314883A202DFF788
Dominick Grift
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQGcBAEBCgAGBQJWip+uAAoJENAR6kfG5xmcdgwL/22baZ8MBVEiE9adrKSgUKal
ig/DmEchlYHuRYvpyEYK7M85vVHpom0vs7X2nAQbxmEnLLYlBdmQzrl872f4lqY8
xR7RPoA1NPKaBtY0yvj4h8AD/AtlSioXB81XMzOTXpss+y1D6HyDur/Grakx86kN
7wA6KVhlQaZEVbuAjBJ3mYt/sQFH6zRg4EKP1r5ebpxWTDdZfI0kwoSD/+cHPct6
HI3/CfOAVBULd/zHn35MKe9njIq2g+5KP7M99h4mziraiA2kVo0mngoWw8yFMjE9
H+4lrG9/J2T8eiPiThqXdw6oFaK7Wu3AP/HYSOcsuFn9U9stMmr7SKG9gBBGn3BL
SUuiekmsG2bNGWf3EmjxUMTlZDxwyVEGv25BgNX0UoxbvHKDAOQS7jYezHqOh6/g
AV5uPa2b27cwRKm03I5R3HtPOJppShjINWuaMDvn7XUD33oNrsH55tWYOiXF6D0E
esIJeUrwtyiGlOiUAYltMtLvqaFvClppxRCMo1545Q==
=EmOE
-END PGP SIGNATURE-


___
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] libselinux: Verify context input to funtions to make sure the context field is not null.

2015-12-17 Thread Joshua Brindle 

Steve Lawrence wrote:

I believe this patch, or something similar, was sent to the list in the
past and was rejected. Passing in a NULL context is considered invalid
use, similar to strdup/strcmp/etc. and is a bug in the calling process.



It isn't unreasonable for an API to indicate invalid usage (which is 
what EINVAL does). The argument that strdup lets you shoot yourself in 
the foot so we should to isn't very compelling...



On 12/09/2015 03:47 PM, Petr Lautrbach wrote:

From: Dan Walsh

Return errno EINVAL, to prevent segfault.

Signed-off-by: Petr Lautrbach
---
  libselinux/src/avc_sidtab.c   | 5 +
  libselinux/src/canonicalize_context.c | 5 +
  libselinux/src/check_context.c| 5 +
  libselinux/src/compute_av.c   | 5 +
  libselinux/src/compute_create.c   | 5 +
  libselinux/src/compute_member.c   | 5 +
  libselinux/src/compute_relabel.c  | 5 +
  libselinux/src/compute_user.c | 5 +
  libselinux/src/fsetfilecon.c  | 8 ++--
  libselinux/src/lsetfilecon.c  | 9 +++--
  libselinux/src/setfilecon.c   | 8 ++--
  11 files changed, 59 insertions(+), 6 deletions(-)

diff --git a/libselinux/src/avc_sidtab.c b/libselinux/src/avc_sidtab.c
index 9669264..a46cfa7 100644
--- a/libselinux/src/avc_sidtab.c
+++ b/libselinux/src/avc_sidtab.c
@@ -81,6 +81,11 @@ sidtab_context_to_sid(struct sidtab *s,
int hvalue, rc = 0;
struct sidtab_node *cur;

+   if (! ctx) {
+   errno = EINVAL;
+   return -1;
+   }
+
*sid = NULL;
hvalue = sidtab_hash(ctx);

diff --git a/libselinux/src/canonicalize_context.c 
b/libselinux/src/canonicalize_context.c
index 7cf3139..9d8dc86 100644
--- a/libselinux/src/canonicalize_context.c
+++ b/libselinux/src/canonicalize_context.c
@@ -17,6 +17,11 @@ int security_canonicalize_context_raw(const char * con,
size_t size;
int fd, ret;

+   if (! con) {
+   errno = EINVAL;
+   return -1;
+   }
+
if (!selinux_mnt) {
errno = ENOENT;
return -1;
diff --git a/libselinux/src/check_context.c b/libselinux/src/check_context.c
index 52063fa..9637dd7 100644
--- a/libselinux/src/check_context.c
+++ b/libselinux/src/check_context.c
@@ -14,6 +14,11 @@ int security_check_context_raw(const char * con)
char path[PATH_MAX];
int fd, ret;

+   if (! con) {
+   errno = EINVAL;
+   return -1;
+   }
+
if (!selinux_mnt) {
errno = ENOENT;
return -1;
diff --git a/libselinux/src/compute_av.c b/libselinux/src/compute_av.c
index 937e5c3..e67b3d3 100644
--- a/libselinux/src/compute_av.c
+++ b/libselinux/src/compute_av.c
@@ -26,6 +26,11 @@ int security_compute_av_flags_raw(const char * scon,
return -1;
}

+   if ((! scon) || (! tcon)) {
+   errno = EINVAL;
+   return -1;
+   }
+
snprintf(path, sizeof path, "%s/access", selinux_mnt);
fd = open(path, O_RDWR);
if (fd<  0)
diff --git a/libselinux/src/compute_create.c b/libselinux/src/compute_create.c
index 9559d42..7de721a 100644
--- a/libselinux/src/compute_create.c
+++ b/libselinux/src/compute_create.c
@@ -64,6 +64,11 @@ int security_compute_create_name_raw(const char * scon,
return -1;
}

+   if ((! scon) || (! tcon)) {
+   errno = EINVAL;
+   return -1;
+   }
+
snprintf(path, sizeof path, "%s/create", selinux_mnt);
fd = open(path, O_RDWR);
if (fd<  0)
diff --git a/libselinux/src/compute_member.c b/libselinux/src/compute_member.c
index 1fc7e41..4ff2173 100644
--- a/libselinux/src/compute_member.c
+++ b/libselinux/src/compute_member.c
@@ -25,6 +25,11 @@ int security_compute_member_raw(const char * scon,
return -1;
}

+   if ((! scon) || (! tcon)) {
+   errno = EINVAL;
+   return -1;
+   }
+
snprintf(path, sizeof path, "%s/member", selinux_mnt);
fd = open(path, O_RDWR);
if (fd<  0)
diff --git a/libselinux/src/compute_relabel.c b/libselinux/src/compute_relabel.c
index 4615aee..6a37acf 100644
--- a/libselinux/src/compute_relabel.c
+++ b/libselinux/src/compute_relabel.c
@@ -25,6 +25,11 @@ int security_compute_relabel_raw(const char * scon,
return -1;
}

+   if ((! scon) || (! tcon)) {
+   errno = EINVAL;
+   return -1;
+   }
+
snprintf(path, sizeof path, "%s/relabel", selinux_mnt);
fd = open(path, O_RDWR);
if (fd<  0)
diff --git a/libselinux/src/compute_user.c b/libselinux/src/compute_user.c
index b37c5d3..3737c28 100644
--- a/libselinux/src/compute_user.c
+++ b/libselinux/src/compute_user.c
@@ -24,6 +24,11 @@ int security_compute_user_raw(const char * scon,
return -1;

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

2015-10-20 Thread Joshua Brindle 

Stephen Smalley wrote:

On 10/20/2015 09:42 AM, Joshua Brindle wrote:

Stephen Smalley wrote:



Wondering if dependency on openssl might be a license issue for Debian
or others. Apparently openssl license is considered GPL-incompatible [1]
[2], and obviously libselinux is linked by a variety of GPL-licensed
programs. Fedora seems to view this as falling under the system library
exception [3] but not clear that other distributions would view it that
way. On the other hand, using gnutls would be subject to the reverse
problem; it would make libselinux depend on a LGPL library, and that
could create issues for non-GPL programs that statically link
libselinux. We might need to revert this change and revisit how to solve
this in a manner that avoids such issues.


LGPL explicitly allows non-GPL programs to link against an LGPL licensed
library without tainting the non-GPL program, which is the whole point
of the LGPL. Is there some other issue with static linking or something?


Yes, that's the concern.


So, not static linking but a fully static binary that would pull gnutls 
into the binary?


What static binaries exist like that? It is not a great idea to carry 
around system level libraries statically.

___
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: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

2015-10-20 Thread Joshua Brindle 

Stephen Smalley wrote:



Wondering if dependency on openssl might be a license issue for Debian
or others. Apparently openssl license is considered GPL-incompatible [1]
[2], and obviously libselinux is linked by a variety of GPL-licensed
programs. Fedora seems to view this as falling under the system library
exception [3] but not clear that other distributions would view it that
way. On the other hand, using gnutls would be subject to the reverse
problem; it would make libselinux depend on a LGPL library, and that
could create issues for non-GPL programs that statically link
libselinux. We might need to revert this change and revisit how to solve
this in a manner that avoids such issues.


LGPL explicitly allows non-GPL programs to link against an LGPL licensed 
library without tainting the non-GPL program, which is the whole point 
of the LGPL. Is there some other issue with static linking or something?




[1] http://www.gnu.org/licenses/license-list.en.html#OpenSSL

[2] https://people.gnome.org/~markmc/openssl-and-the-gpl.html

[3]
https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F)


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