headers
Paul Moore | 1 Mar 2010 02:01
Picon
Favicon

Re: [PATCH] netlabel: fix export of SELinux categories > 127

On Friday 26 February 2010 01:08:03 pm Joshua Roys wrote:
> On 02/24/2010 06:52 PM, Paul Moore wrote:
> > On Wednesday 24 February 2010 11:52:37 am Joshua Roys wrote:
> >> This fixes corrupted CIPSO packets when SELinux categories greater
> >> than 127 are used.  The bug occured on the second (and later) loops
> >> through the while; the inner for loop through the ebitmap->maps array
> >> used the same index as the NetLabel catmap->bitmap array, even though
> >> the NetLabel bitmap is twice as long as the SELinux bitmap.
> >> 
> >> Signed-off-by: Joshua Roys<joshua.roys@...>
> > 
> > Ha!  I came to the same conclusion and sent you a similar patch a few
> > hours ago (should have checked my SELinux email folder first it seems).
> > 
> > Acked-by: Paul Moore<paul.moore@...>
> > 
> > This should also be sent to stable - James or Josh do one of you guys
> > want to do that?
> 
> Cool!  I'm glad we came to the same solution, although next time I'll CC
> you directly to avoid doing duplicate work.

Okay, no problem either way - the important part is that the problem is now 
fixed.

> Thanks for your help,

Thanks to you as well, it's always nice to see others get involved.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
KaiGai Kohei | 1 Mar 2010 03:43
Picon

Re: [PATCH 2/2] libsepol: remove dead code in check_avtab_hierarchy_callback()

(2010/02/20 0:20), Stephen Smalley wrote:
> On Fri, 2010-02-19 at 16:33 +0900, KaiGai Kohei wrote:
>> (2010/02/17 22:51), Stephen Smalley wrote:
>>> On Wed, 2010-02-17 at 08:49 +0900, KaiGai Kohei wrote:
>>>>> I'd say we revert the changeset and restore the prior behavior.
>>>>> I don't think we should impose the latter convention on policy writers.
>>>>
>>>> OK, fair enough for me.
>>>>
>>>> This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801
>>>> which removed a part of type_attribute_bounds_av as a dead code.
>>>> However, at that time, we didn't find out the target side boundary allows
>>>> to handle some of pseudo /proc/≤pid>/* entries with its process's security
>>>> context well.
>>>
>>> Does Jacques' original concern about the code still hold true?
>>> http://marc.info/?l=selinux&m=125770868309928&w=2
>>> http://marc.info/?l=selinux&m=125851264424682&w=2
>>
>> This patch just tries to revert the changes by previous my patch,
>> and returns to the start point, so it also reverts the Jacques'
>> original concern.
>>
>> At that time, IIRC, Jacques concerned about the logic being unclear.
>> Then, I introduced two options. The one is rough; that removes boundary
>> checks in the target side. The other option tried to mask union bits of
>> both of violated permissions on subject and target side boundaries (*1).
>>
>>   (*1) type_attribute_bounds_av(Sc,Tc, ...)
>>        {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Smalley | 1 Mar 2010 15:10
Picon

Re: denials with filesystem associate

On Sun, 2010-02-28 at 23:38 +0100, Michal Svoboda wrote:
> Hello,
> 
> see log below... what could be causing these denials? And, what
> operations exactly are those?

On file creation, there is an associate check between the security
context of the file and the security context of the containing
filesystem.  In your particular case though the real issue is that you
have an unlabeled filesystem type that needs a genfscon or fs_use rule
added to your policy.   Look for a log message that says something along
the lines of:
SELinux:  initialized (dev ..., type ...), not configured for labeling

You might need to enable kern.debug logging in your syslog
configuration.

> 
> With regards,
> Michal Svoboda
> 
> [    0.000000] Linux version 2.6.32-trunk-amd64 (Debian 2.6.32-5)
> (ben@...) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Sun
> Jan 10 22:40:40 UTC 2010
> [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-2.6.32-trunk-amd64
> root=UUID=6f30ce45-1f28-4abb-9271-aa56e2af839d ro selinux=1
> 
> ...
> 
> [    2.840057] usb 1-2: new full speed USB device using uhci_hcd and
(Continue reading)

Permalink | Reply | 12 comments |
headers
Stephen Smalley | 1 Mar 2010 15:34
Picon

Re: [PATCH 2/2] libsepol: remove dead code in check_avtab_hierarchy_callback()

On Mon, 2010-03-01 at 11:43 +0900, KaiGai Kohei wrote:
> (2010/02/20 0:20), Stephen Smalley wrote:
> > On Fri, 2010-02-19 at 16:33 +0900, KaiGai Kohei wrote:
> >> (2010/02/17 22:51), Stephen Smalley wrote:
> >>> On Wed, 2010-02-17 at 08:49 +0900, KaiGai Kohei wrote:
> >>>>> I'd say we revert the changeset and restore the prior behavior.
> >>>>> I don't think we should impose the latter convention on policy writers.
> >>>>
> >>>> OK, fair enough for me.
> >>>>
> >>>> This patch revert the commit of 7d52a155e38d5a165759dbbee656455861bf7801
> >>>> which removed a part of type_attribute_bounds_av as a dead code.
> >>>> However, at that time, we didn't find out the target side boundary allows
> >>>> to handle some of pseudo /proc/≤pid>/* entries with its process's security
> >>>> context well.
> >>>
> >>> Does Jacques' original concern about the code still hold true?
> >>> http://marc.info/?l=selinux&m=125770868309928&w=2
> >>> http://marc.info/?l=selinux&m=125851264424682&w=2
> >>
> >> This patch just tries to revert the changes by previous my patch,
> >> and returns to the start point, so it also reverts the Jacques'
> >> original concern.
> >>
> >> At that time, IIRC, Jacques concerned about the logic being unclear.
> >> Then, I introduced two options. The one is rough; that removes boundary
> >> checks in the target side. The other option tried to mask union bits of
> >> both of violated permissions on subject and target side boundaries (*1).
> >>
> >>   (*1) type_attribute_bounds_av(Sc,Tc, ...)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ulrich Althaus | 1 Mar 2010 16:34
Favicon

RHEL4 Selinux mailinglist

Hi,

if I have problems with telnet in RHEL4, which mailing list should I
write to?

Regards
Ulrich
-- 
-------------------------------------------------------------------------------------------------
Ulrich Althaus
TriaGnoSys GmbH
Argelsrieder Feld 22
D-82234 Wessling-Oberpfaffenhofen
Germany

Tel: +49 8153 88678-218
Fax:+49 8153 88678-1

email: Ulrich.Althaus@...
www: http://www.triagnosys.com
------------------------------------
TriaGnoSys GmbH, Registergericht: München HRB 141647, Vat. :DE 813396184
Geschäftsführer: Matthias Holzbock, Dr. Axel Jahn, Dr. Markus Werner

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you are not the addressee or authorized to receive this
for the addressee, you must not use, copy, disclose or take any action
based on this message or any information herein. If you have received
this message in error, please advise the sender immediately by replying
(Continue reading)

Permalink | Reply | 5 comments |
headers
Daniel J Walsh | 1 Mar 2010 17:08
Picon
Favicon
Gravatar

Re: RHEL4 Selinux mailinglist

On 03/01/2010 10:34 AM, Ulrich Althaus wrote:
> Hi,
>
> if I have problems with telnet in RHEL4, which mailing list should I
> write to?
>
> Regards
> Ulrich
>    
Depends on what the problem is.  The official response probably would be 
open a bugzilla.  Or talk to your support person.

What is the problem you are seeing?
Permalink | Reply | 4 comments |
headers
Ulrich Althaus | 1 Mar 2010 17:30
Favicon

Re: RHEL4 Selinux mailinglist


Am 01.03.2010 17:08, schrieb Daniel J Walsh:
> On 03/01/2010 10:34 AM, Ulrich Althaus wrote:
>> Hi,
>>
>> if I have problems with telnet in RHEL4, which mailing list should I
>> write to?
>>
>> Regards
>> Ulrich
>>    
> Depends on what the problem is.  The official response probably would be
> open a bugzilla.  Or talk to your support person.
> 
> What is the problem you are seeing?
> 

I have a RHEL4 Server on which I cannot execute telnet when being in
enforcing mode, while in permissive mode it works without any problems.
Plus I don't get any avc denies.

--

-- 
-------------------------------------------------------------------------------------------------
Ulrich Althaus
TriaGnoSys GmbH
Argelsrieder Feld 22
D-82234 Wessling-Oberpfaffenhofen
Germany

Tel: +49 8153 88678-218
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michal Svoboda | 1 Mar 2010 17:56
Picon
Picon
Favicon

Re: denials with filesystem associate

Stephen Smalley wrote:
> On file creation, there is an associate check between the security
> context of the file and the security context of the containing
> filesystem.  

Is there anything I could read up to understand this mechanism?

> In your particular case though the real issue is that you
> have an unlabeled filesystem type that needs a genfscon or fs_use rule
> added to your policy.   Look for a log message that says something along
> the lines of:
> SELinux:  initialized (dev ..., type ...), not configured for labeling

[    2.780406] SELinux: initialized (dev devtmpfs, type devtmpfs), not
configured for labeling

I think this is the new kernel-make dev filesystem that appears in .32
or so. So I need to recompile the base module to use transition SIDs,
like on normal tmpfs, right?

Regards,
Michal Svoboda
Permalink | Reply | 11 comments |
headers
Daniel J Walsh | 1 Mar 2010 17:50
Picon
Favicon
Gravatar

Re: RHEL4 Selinux mailinglist

On 03/01/2010 11:30 AM, Ulrich Althaus wrote:
>
> Am 01.03.2010 17:08, schrieb Daniel J Walsh:
>    
>> On 03/01/2010 10:34 AM, Ulrich Althaus wrote:
>>      
>>> Hi,
>>>
>>> if I have problems with telnet in RHEL4, which mailing list should I
>>> write to?
>>>
>>> Regards
>>> Ulrich
>>>
>>>        
>> Depends on what the problem is.  The official response probably would be
>> open a bugzilla.  Or talk to your support person.
>>
>> What is the problem you are seeing?
>>
>>      
> I have a RHEL4 Server on which I cannot execute telnet when being in
> enforcing mode, while in permissive mode it works without any problems.
> Plus I don't get any avc denies.
>
>
>
>    
id -Z
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Smalley | 1 Mar 2010 18:09
Picon

Re: denials with filesystem associate

On Mon, 2010-03-01 at 17:56 +0100, Michal Svoboda wrote:
> Stephen Smalley wrote:
> > On file creation, there is an associate check between the security
> > context of the file and the security context of the containing
> > filesystem.  
> 
> Is there anything I could read up to understand this mechanism?

The particular permission checks for operations were described in:
http://www.nsa.gov/research/_files/selinux/papers/slinux-abs.shtml
and
http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml

There is also a wiki page with information on classes and permissions,
http://www.selinuxproject.org/page/ObjectClassesPerms

> > In your particular case though the real issue is that you
> > have an unlabeled filesystem type that needs a genfscon or fs_use rule
> > added to your policy.   Look for a log message that says something along
> > the lines of:
> > SELinux:  initialized (dev ..., type ...), not configured for labeling
> 
> [    2.780406] SELinux: initialized (dev devtmpfs, type devtmpfs), not
> configured for labeling
> 
> I think this is the new kernel-make dev filesystem that appears in .32
> or so. So I need to recompile the base module to use transition SIDs,
> like on normal tmpfs, right?

Yes.  Looks like Fedora policy has:
(Continue reading)

Permalink | Reply | 10 comments |

Gmane