[prev in list] [next in list] [prev in thread] [next in thread] 

List:       selinux
Subject:    Re: [PATCH] libselinux:
From:       "Christopher J. PeBenito" <cpebenito () tresys ! com>
Date:       2008-05-30 12:27:36
Message-ID: 1212150456.31546.16.camel () gorn
[Download RAW message or body]

On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote:
> Christopher J. PeBenito wrote:
> > On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote:
> >   
> >> Christopher J. PeBenito wrote:
> >>     
> >>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
> >>>   
> >>>       
> >>>> Christopher J. PeBenito wrote:
> >>>>     
> >>>>         
> >>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> >>>>>>         
> >>>>>>             
> >>>>>>> I mainly had an issue with statements like:
> >>>>>>>
> >>>>>>> type_transition postgresql_t postgresql_t:db_database sepgsql_db_t;
> >>>>>>> type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t;
> >>>>>>> type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t;
> >>>>>>> type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t;
> >>>>>>> type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;
> >>>>>>>       
> >>>>>>>           
> >>>>>>>               
> >>>> I don't see the problem with the above statements - seems like a 
> >>>> reasonable use of transitions to me.  If you don't like the first four 
> >>>> transitions, then I would ask -- why not simply eliminate the target 
> >>>> types in those rules and label all of those objects with postgresql_t 
> >>>> (default transition)?  Clearly the names are just for convenience.  You 
> >>>> did a similar thing with the X policy: going through and combining types.
> >>>>     
> >>>>         
> >>> I don't think this is the same situation.  Having a table labeled
> >>> postgresql_t doesn't make sense to me, since postgresql_t is the type of
> >>> the server process.  Though, I suppose that if it wasn't an object
> >>> manager, then the objects would implicitly be postgresql_t and/or
> >>> postgresql_db_t.  So to conclude my stream of consciousness, I'm
> >>> compelled by your argument, but I'm not sure its enough to change my
> >>> position
> >>>       
> >> If it's not the same situation, it sounds pretty darn close: the X 
> >> server also acts as a "client" when it starts up, and various objects 
> >> are created by the server before any real clients connect.  For example 
> >> root window and default colormap.
> >>
> >>  From xserver.if:
> >>
> >>         # Labeling rules for default windows and colormaps
> >>         type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;
> >>     
> >
> > Its significantly different since this deals with derived types while
> > postgres doesn't.
> >   
> 
> That's the policy writer's decision to make.  What if I make my own 
> policy and I want to use derived types for postgres?

I never argued that type transitions shouldn't work.  My problem is the
default type in the absence of type transitions.  In fact there are
derived types in the current postgres policy, and I'm fine with them.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
[prev in list] [next in list] [prev in thread] [next in thread]