Re: SE-PostgreSQL for Fedora (Re: Guideline for RPM packages)

[KaiGai Kohei]

>  Err, I think you should be using the new userland discovery
> interface
>  for this, hardcoding at compile time is a very bad idea (it makes the
>  compiled binaries completely non-portable).
>  
>  look at libselinux/checkAccess.c in the trunk version to see how it is
>  used, essentially something like:
>  
>  dbase_class = string_to_security_class("database");
>  if (dbase_class == 0)
>  return 0;
>  
>  That lets you discover the class offset at runtime. There are also
>  facilities for doing the same with permissions. 
SE-PostgreSQL can already use the userland discovert interdace, if the kernel
provides it. But it is available at the only latest kernel, now.
We have to be also able to apply hardcoded object class number for a while,
to work on the current kernel (2.6.22 or older).

Otherwise, we have to replace or modify the base policy to add definitions of
new object classes and access vectors related to database, so we want these
definitions are integrated into the base policy.

Thanks,

> > As you mentioned, I also think this trick is not a good idea.
> > However, the number of object classes is not constant between policy versions,
> > so I had to handle the difference and to follow the version up.
> > I modified it by hand at first, but conditional definition for SECCLASS_DATABASE
> > got necessary, because the number of object classes got differ between Fedora core 6
> > and Fedora 7.
> >
> > I think integration of these definitions into the base policy is the best way
> > to avoid such a ugly implementation. :)
> >
> > Thanks,
> >
> >   
> >> As an aside to this, I notice that you tried to integrate policy
> >> management into the RPM, and I had to modify my spec file to not do this
> >> because I have my own custom policies on the system. I don't think this
> >> is the best way, long term, to handle policy integration, though,
> >> unfortunately, I don't have any better suggestions. This is something I
> >> intend to look into soon though so I'll provide some feedback on the
> >> previous thread when I have something useful to say :)
> >>     
> > --
> > KaiGai Kohei <kaigai(a)kaigai.gr.jp&gt; 
-- 
KaiGai Kohei <kaigai(a)kaigai.gr.jp&gt;