headers
Russell Coker | 5 Jan 2011 09:30
Picon

libsemanage patch for MCS/MLS in user files

The attached patch makes the 
/etc/selinux/default/contexts/files/file_contexts.homedirs generation process 
include the MCS/MLS level.

This means that if you have a user with a MCS/MLS level that isn't SystemLow 
then their home directory will be labeled such that they can have read/write 
access to it by default.

Unless anyone has any better ideas for how to solve this problem I will upload 
this to Debian shortly.

What do the MLS users do in this situation?  Just relabel home directories 
manually?

Finally it seems that when you run "semanage user -m" the 
file_contexts.homedirs doesn't get updated, it's only when you run
"semanage login -m" that it takes affect.

--

-- 
russell@...
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog
Attachment (diff): text/x-patch, 6158 bytes
Permalink | Reply | 2 comments |
headers
Joe Nall | 5 Jan 2011 15:36
Favicon

Re: libsemanage patch for MCS/MLS in user files


On Jan 5, 2011, at 2:30 AM, Russell Coker wrote:

> The attached patch makes the 
> /etc/selinux/default/contexts/files/file_contexts.homedirs generation process 
> include the MCS/MLS level.
> 
> This means that if you have a user with a MCS/MLS level that isn't SystemLow 
> then their home directory will be labeled such that they can have read/write 
> access to it by default.
> 
> Unless anyone has any better ideas for how to solve this problem I will upload 
> this to Debian shortly.
> 
> What do the MLS users do in this situation?  Just relabel home directories 
> manually?

We don't have any users that are single level > SystemLow. I do think that is a
legitimate use case. We currently symlink most dot files into a polyinstatiated
directory to allow terminal windows and preferences to work at multiple levels.

You could polyinstantiate the home directory and not worry about the specific
level.

joe

> 
> 
> Finally it seems that when you run "semanage user -m" the 
> file_contexts.homedirs doesn't get updated, it's only when you run
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russell Coker | 5 Jan 2011 23:46
Picon

Re: libsemanage patch for MCS/MLS in user files

On Thu, 6 Jan 2011, Joe Nall <joe@...> wrote:
> We don't have any users that are single level > SystemLow. I do think that
> is a legitimate use case. We currently symlink most dot files into a
> polyinstatiated directory to allow terminal windows and preferences to
> work at multiple levels.
> 
> You could polyinstantiate the home directory and not worry about the
> specific level.

I want to support a fairly simplistic use case where PI isn't required, all 
that's required is that a few users who access sensitive data can't share it 
easily.

Thanks for your comment, I'll upload this package to Debian.

--

-- 
russell@...
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog
Permalink | Reply | 0 comments |
headers
KaiGai Kohei | 6 Jan 2011 08:14
Picon

[libselinux] add db_language support on label_db.c

The attached patch add support db_language object class
to the selabel_lookup(_raw) interfaces.
It is needed to inform object manager initial label of
procedural language object.

Thanks,
--

-- 
KaiGai Kohei <kaigai@...>
Attachment (libselinux-selabel.1.patch): text/x-patch, 941 bytes
Permalink | Reply | 3 comments |
headers
Chad Sellers | 6 Jan 2011 22:41
Favicon

SELinux Symposium site

Apologies to anyone who has had trouble accessing the old SELinux Symposium
site of late. We had a bit of trouble with the domain name. You can now find
the site at:

http://selinuxsymposium.org/

Again, sorry for any inconvenience of it going down.

Thanks,
Chad Sellers
Permalink | Reply | 0 comments |
headers
Russell Coker | 9 Jan 2011 06:56
Picon

iodine and SE Linux

I notice that iodine (IP over DNS tunnel daemon) has sample SE Linux policy 
and a SE Linux patch to the source code.

The way it works is that you give iodine a -z parameter with the context that 
you want and it then calls setcon() to get it.

What I am thinking of doing is writing policy for iodine, icmptx, and any 
other daemon that operates in a similar manner that has an automatic domain 
transition and no setcon().  I am thinking of making this tunnel_t.

What do you think?

--

-- 
russell@...
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog
Permalink | Reply | 2 comments |
headers
Daniel J Walsh | 12 Jan 2011 19:36
Picon
Favicon
Gravatar

SELinux Policy compiler doesn't like leading numbers in fs names


https://bugzilla.redhat.com/show_bug.cgi?id=668871

Is there any logical reason for this or is this just a bug?
Permalink | Reply | 2 comments |
headers
Daniel J Walsh | 12 Jan 2011 19:59
Picon
Favicon
Gravatar

Re: SELinux Policy compiler doesn't like leading numbers in fs names


On 01/12/2011 01:56 PM, James Carter wrote:
> On Wed, 2011-01-12 at 13:36 -0500, Daniel J Walsh wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=668871
> 
> Is there any logical reason for this or is this just a bug?
> 
>> The filesystem name for a genfscon statement happens to be specified as
>> an identifier and an identifier must begin with a letter, but I don't
>> think that there is any technical reason for the restriction.
> 
>> Would we want to allow all identifiers to be able to start with
>> alphanumeric characters (or maybe even "_") or just filesystem names?
> 
>>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@...
with
the words "unsubscribe selinux" without quotes as the message.

I would say allow any alphanumeric and _, and then let the refpolicy
guidelines control what gets into that policy.  Forcing IBM to change
the name of their file system for SELinux seems a little nuts.
Permalink | Reply | 0 comments |
headers
James Carter | 12 Jan 2011 19:56
Picon

Re: SELinux Policy compiler doesn't like leading numbers in fs names

On Wed, 2011-01-12 at 13:36 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=668871
> 
> Is there any logical reason for this or is this just a bug?

The filesystem name for a genfscon statement happens to be specified as
an identifier and an identifier must begin with a letter, but I don't
think that there is any technical reason for the restriction.

Would we want to allow all identifiers to be able to start with
alphanumeric characters (or maybe even "_") or just filesystem names?

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk0t9LwACgkQrlYvE4MpobOnqACg4Hj22Ioqgopb96HTvJ0ZkrmO
> 02gAnAlpIDBLjSTQkoOvah/S535YePCM
> =65GT
> -----END PGP SIGNATURE-----
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@... with
> the words "unsubscribe selinux" without quotes as the message.

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christopher J. PeBenito | 12 Jan 2011 21:12
Favicon

Re: iodine and SE Linux

On 1/9/2011 12:56 AM, Russell Coker wrote:
> I notice that iodine (IP over DNS tunnel daemon) has sample SE Linux policy
> and a SE Linux patch to the source code.
>
> The way it works is that you give iodine a -z parameter with the context that
> you want and it then calls setcon() to get it.
>
> What I am thinking of doing is writing policy for iodine, icmptx, and any
> other daemon that operates in a similar manner that has an automatic domain
> transition and no setcon().  I am thinking of making this tunnel_t.
>
> What do you think?

I'm not familiar with these tunnel services; does it make sense to adapt 
the existing stunnel policy?  Or if we went to a tunnel_t generic 
service, would it be possible to get stunnel over to it?

--

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
Permalink | Reply | 1 comment |

Gmane