Re: SELinux userspace infrastructure language

On Thu, 2007-05-31 at 20:45 +0100, Stephen Bennett wrote:
> On Thu, 31 May 2007 13:54:23 -0400
> "Joshua Brindle" <jbrindle@...> wrote:
> 
> > Given all this I think C++ is the best bet, though I'm not adverse to
> > most of the frontends being written in python, it would just be nice
> > if the actual policy representation and accessors are available from a
> > shared library API that most languages can use.
> 
> From the library side, C++ has the advantage that it can produce
> bindings for any language that C can.

 Do you have a examples of this? From what little I know it's _much_
harder to produce usable bindings from C++, the Qt/KDE bindings seem to
have been in the works for years now and AIUI only very recently[1] got
into KDE's stable branch. With the first non-C++ application being
written in ... python.
 Even assuming everyone could cooperatively write good C++ code from
scratch using just the right C++ features, which is a huge
assumption[2], it then has to be debugged and then after all that work
all you'll gain is that you can then bind to python (and maybe,
Java/ruby) as well?
 Is anyone writing anything in a language other than C or Python?

>  Writing a library in python
> pretty much guarantees that noone will write anything using it in
> anything but python, and on smaller systems the python interpreter can
> get to be a lot of overhead.

 True, but you can still import C etc. into it if you really need the

Re: SELinux userspace infrastructure language

On Fri, 1 Jun 2007 12:40:53 +0100
Stephen Bennett <spb@...> wrote:

> On Fri, 01 Jun 2007 00:10:15 -0400
> James Antill <jantill@...> wrote:
> 
> > > From the library side, C++ has the advantage that it can produce
> > > bindings for any language that C can.
> > 
> >  Do you have a examples of this? From what little I know it's _much_
> > harder to produce usable bindings from C++, the Qt/KDE bindings seem
> > to have been in the works for years now and AIUI only very
> > recently[1] got into KDE's stable branch. With the first non-C++
> > application being written in ... python.
> 
> I know from recent experience that Ruby and Python can be done
> directly without too much trouble. If anything else is needed that
> particularly defies bindings in C++, one can (in principle, and if
> you haven't relied upon too many of the more advanced language
> features) create a C API by turning all object pointers into opaque
> types and wrapping methods in regular function calls, then go from
> that.

The example I had in mind being
http://paludis.pioto.org/trac/browser/trunk -- the ruby/ and python/
directories contain the bindings for those languages. The library
itself is a lot of pretty 'heavy' C++. The Python interface uses the
Boost library for convenience, whereas Ruby uses the Ruby/C API
directly.

Re: SELinux userspace infrastructure language

On Fri, 01 Jun 2007 00:10:15 -0400
James Antill <jantill@...> wrote:

> > From the library side, C++ has the advantage that it can produce
> > bindings for any language that C can.
> 
>  Do you have a examples of this? From what little I know it's _much_
> harder to produce usable bindings from C++, the Qt/KDE bindings seem
> to have been in the works for years now and AIUI only very
> recently[1] got into KDE's stable branch. With the first non-C++
> application being written in ... python.

I know from recent experience that Ruby and Python can be done directly
without too much trouble. If anything else is needed that particularly
defies bindings in C++, one can (in principle, and if you haven't
relied upon too many of the more advanced language features) create a C
API by turning all object pointers into opaque types and wrapping
methods in regular function calls, then go from that.

policycoreutils patch

policycoreutils should be checking if the user is the default_type not 
hard coded to user_u.

Also if selinux is not enabled, the verification step should not 
happen.  This is causing problems in chroot environments for the install.

Both these fixes should go into the new genhomedircon that is being 
added to semanage.

diff --exclude-from=exclude --exclude=sepolgen-1.0.8 --exclude=gui --exclude=po -N -u -r
nsapolicycoreutils/scripts/genhomedircon policycoreutils-2.0.19/scripts/genhomedircon
--- nsapolicycoreutils/scripts/genhomedircon	2007-05-18 09:58:33.000000000 -0400
+++ policycoreutils-2.0.19/scripts/genhomedircon	2007-06-01 10:29:32.000000000 -0400
 <at>  <at>  -193,7 +193,7  <at>  <at> 
 		return prefix
 		
 	def adduser(self, udict, user, seuser, prefix):
-		if seuser == "user_u" or user == "__default__" or user == "system_u":
+		if seuser == self.default_user or user == "__default__" or user == "system_u":
 			return
 		# !!! chooses first prefix in the list to use in the file context !!!
 		try:
 <at>  <at>  -263,7 +263,7  <at>  <at> 
 				i = i.replace("system_u", seuser)
 				# Validate if the generated context exists.  Some user types may not exist
 				scon = i.split()[-1]
-				if selinux.security_check_context(scon) == 0:
+				if selinux.is_selinux_enabled() < 1 or selinux.security_check_context(scon) == 0:
 					ret = ret+i

Re: With the release of Fedora Core 7 I have bumped the policy version in Rawhide

On Thu, 2007-05-31 at 14:54 -0400, Daniel J Walsh wrote:
> Tomorrows rawhide will have selinux-policy-3.0.1. 
> 
> This policy is the first release of the merged (strict/targeted) 
> policy.  As such there is no longer a selinux-policy-strict.  This is 
> real experimental and I expect some problems.  I have been running it 
> here for a couple of days. 
> 
> With this policy you can install the strict type users staff_u, user_u, 
> sysadm_u.  As well as the unonfined_u/system_u.  You should be able to 
> mix and match the users.  So if you want to setup a Guest X-Windows 
> login you would set it up with a user of user_u:user_r:user_t.  And you 
> might have your regular login as system_u:unconfined_r:unconfined_t.

As a side note is that an unconfined_u seuser is going to be added,
which will be the appropriate seuser to use for unconfined users.  So
eventually you'll end up with unconfined_u:unconfined_r:unconfined_t.

> The idea is if you remove the unconfined policy package, you will be 
> basically running in strict policy mode.  (This has not been tested.) 

Actually you also have to take out anaconda and firstboot since they
unconditionally depend on unconfined.  Otherwise it should work.

--

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

RE: SELinux userspace infrastructure language

Karl MacMillan wrote:
> On Fri, 2007-06-01 at 00:10 -0400, James Antill wrote:
>> On Thu, 2007-05-31 at 20:45 +0100, Stephen Bennett wrote:
>>> On Thu, 31 May 2007 13:54:23 -0400
>>> "Joshua Brindle" <jbrindle@...> wrote:
>>> 
>>>> Given all this I think C++ is the best bet, though I'm not adverse
>>>> to most of the frontends being written in python, it would just be
>>>> nice if the actual policy representation and accessors are
>>>> available from a shared library API that most languages can use.
>>> 
>>> From the library side, C++ has the advantage that it can produce
>>> bindings for any language that C can.
>> 
>>  Do you have a examples of this? From what little I know it's _much_
>> harder to produce usable bindings from C++, the Qt/KDE bindings seem
>> to have been in the works for years now and AIUI only very
>> recently[1] got into KDE's stable branch. With the first non-C++
>> application being written in ... python.
> 
> It's a matter of how idiomatic you want the bindings and what
> the C++ code looks like. If you stick to fairly
> straightforward C++ code then the bindings are pretty simple.
> If you use lots of advanced features then things can be strange.
> 
>>  Even assuming everyone could cooperatively write good C++ code from
>> scratch using just the right C++ features, which is a huge
>> assumption[2], it then has to be debugged and then after all that
>> work all you'll gain is that you can then bind to python (and maybe,
>>  Java/ruby) as well? Is anyone writing anything in a language other

Re: SELinux userspace infrastructure language

On Fri, 2007-06-01 at 00:10 -0400, James Antill wrote:
> On Thu, 2007-05-31 at 20:45 +0100, Stephen Bennett wrote:
> > On Thu, 31 May 2007 13:54:23 -0400
> > "Joshua Brindle" <jbrindle@...> wrote:
> > 
> > > Given all this I think C++ is the best bet, though I'm not adverse to
> > > most of the frontends being written in python, it would just be nice
> > > if the actual policy representation and accessors are available from a
> > > shared library API that most languages can use.
> > 
> > From the library side, C++ has the advantage that it can produce
> > bindings for any language that C can.
> 
>  Do you have a examples of this? From what little I know it's _much_
> harder to produce usable bindings from C++, the Qt/KDE bindings seem to
> have been in the works for years now and AIUI only very recently[1] got
> into KDE's stable branch. With the first non-C++ application being
> written in ... python.

It's a matter of how idiomatic you want the bindings and what the C++
code looks like. If you stick to fairly straightforward C++ code then
the bindings are pretty simple. If you use lots of advanced features
then things can be strange.

>  Even assuming everyone could cooperatively write good C++ code from
> scratch using just the right C++ features, which is a huge
> assumption[2], it then has to be debugged and then after all that work
> all you'll gain is that you can then bind to python (and maybe,
> Java/ruby) as well?
>  Is anyone writing anything in a language other than C or Python?

Re: With the release of Fedora Core 7 I have bumped the policy version in Rawhide

Christopher J. PeBenito wrote:
> On Thu, 2007-05-31 at 14:54 -0400, Daniel J Walsh wrote:
>   
>> Tomorrows rawhide will have selinux-policy-3.0.1. 
>>
>> This policy is the first release of the merged (strict/targeted) 
>> policy.  As such there is no longer a selinux-policy-strict.  This is 
>> real experimental and I expect some problems.  I have been running it 
>> here for a couple of days. 
>>
>> With this policy you can install the strict type users staff_u, user_u, 
>> sysadm_u.  As well as the unonfined_u/system_u.  You should be able to 
>> mix and match the users.  So if you want to setup a Guest X-Windows 
>> login you would set it up with a user of user_u:user_r:user_t.  And you 
>> might have your regular login as system_u:unconfined_r:unconfined_t.
>>     
>
> As a side note is that an unconfined_u seuser is going to be added,
> which will be the appropriate seuser to use for unconfined users.  So
> eventually you'll end up with unconfined_u:unconfined_r:unconfined_t.
>
>   

>> The idea is if you remove the unconfined policy package, you will be 
>> basically running in strict policy mode.  (This has not been tested.) 
>>     
>
> Actually you also have to take out anaconda and firstboot since they
> unconditionally depend on unconfined.  Otherwise it should work.
>

Re: object class discovery userland

KaiGai Kohei wrote:
>> I think that because of the heavy customization in the Postgres AVC 
>> implementation it is best kept outside-of-tree at the current time.
> 
> OK,
> 
>> There are other applications that use process pools such as Apache and 
>> if these become hosts to object managers then it may be useful to 
>> provide a shared memory option in the libselinux version.  The solution 
>> would involve a flag to the init function, some method of providing the 
>> shared memory segment to attach to, and special functionality for the 
>> "manager" process that will listen on netlink.
> 
> Can I consider those features as a future todo? Or, do you want to have
> a discussion in this chance?

Future todo.

> 
>> However, the Postgres implementation is not fully "shared memory" based. 
>>  The SID-to-context mapping is kept in a "pg_selinux" database table 
>> which is not stored in shared memory but rather is mapped from disk 
>> (correct me if I'm wrong). 
> 
> It's correct. SE-PostgreSQL leverages one of the subsystems provided by native
> PostgreSQL, to implement SID-to-context mapping. It is not based on share memory
> directly.
> 
>> In the previous thread, the possibility of 
>> providing callbacks for doing the SID-to-context mapping was discussed. 

[PATCH] libselinux: string representation refactoring

This patch splits the string representation functions out of avc.c
and refactors the AVC code to use the interface functions instead
of the raw tables when building AVC messages.

These changes should make it easier to add the dynamic class and
permission support (Chris, take note).

The "print_access_vector" function should probably be deprecated at
some point.  IIRC it was used by some utility that now doesn't use
it anymore.

Signed-off-by: Eamon Walsh <ewalsh@...>

---

 avc.c       |  408 +-----------------------------------------------------------
 stringrep.c |  328 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 341 insertions(+), 395 deletions(-)

Index: libselinux/src/avc.c
===================================================================
--- libselinux/src/avc.c	(revision 2456)
+++ libselinux/src/avc.c	(working copy)
 <at>  <at>  -7,151 +7,13  <at>  <at> 
  * Stephen Smalley <sds@...> and 
  * James Morris <jmorris@...>.
  */
-#include <sys/types.h>
-#include <errno.h>
-#include <stddef.h>