[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#249496: Debian / SE/Linux - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249496

On Sat, May 29, 2004 at 10:32:05PM -0300, Scott James Remnant wrote:
> On Sat, 2004-05-29 at 21:46 +0000, Luke Kenneth Casson Leighton wrote:
> > i'm doing a status report on the progress of Debian SE/Linux
> > support.
> > 
> Ok...
> > i'm aware that the postinst.d patch is well-known, shall we say.
> > what news can i put into the status report?
> > 
> The patch hasn't been accepted, any dpkg triggers support needs to be
> complete and full-featured and not a temporary hack.

 oh.  right.  um, okay.

 so that's related to the other reports, like #17243 etc., yes?


 so, on the one hand, i am puzzled, because i feel that the ethos
 of "little and often" increments, especially when contributed from
 several people, makes for continuous progress: how can someone
 with only a few spare hours contribute another part of the larger
 picture unless they have some of the pieces to cut/paste?

 on the _other_ hand, i realise that this is quite a significant
 addition to dpkg functionality, that it may not fit with what
 may have already been discussed as the way forward: consequently,
 what may end up in dpkg might not necessarily be a postinst.d

 this makes things slightly awkward.   SE/Linux needs the
 postinst.d thing, or equivalent, _now_ not later, because the
 files listed in any package being installed _must_ have their
 SE/Linux security permissions set, and it is unreasonable to
 expect each and every package to be modified to perform that

 consequently, anyone wishing to use SE/Linux on Debian must
 continue to download a separately maintained and
 non-debian-mainline-controlled dpkg, from
 http://selinux.lemuria.org/newselinux/dpkg, and if they don't
 install that version, they can expect their system to break
 whenever they install a new package, or to have to manually
 run "setfiles" - the file security setting program - themselves.

 not that i'm twisting your arm or anything: i'm just outlining
 logically, objectively and without prejudice what the knock-on
 effects of the decision not to accept that patch are.

 [i don't know anything about you, so i don't know if you'll
  be offended by this approach: i'd appreciate knowing that
  you don't intend to shoot the messenger :) ]

 the workarounds are to have the linux kernel do it,
 at file create time, to store the security file_contexts "map"
 somewhere in the kernel.
 or to have a user-space trigger on each and every single file
 create that runs the setfiles program.

 neither of these two are really viable options: adding stuff
 to the linux kernel, especially when the security file_contexts
 "map" can be extremely large...  ... and running a user-space
 trigger on _every_ file create just in case it _might_ be in
 the file_contexts map?  naaah :)

 so.  summary.

 1) postinst.d patch not yet accepted upstream as it's one
    part of a larger picture that hasn't been finalised.

 2) therefore people using Debian/SELinux must at present
    use a separately maintained dpkg.

 3) workarounds involving the kernel are not viable.

 therefore, it necessary to get whatever plans for a
 postinst.d replacement / equivalent in place and working


 1) where can i find information / references to plans and
    discussions on postinst.d equivalent functionality?

 2) is there a functional specification already outlined
    that i can quickly implement?

 3) if there isn't a functional specification already
    outlined, whom can i approach to encourage them to
	write one?

 4) if neither 2) nor 3) works, what would it take to
    persuade people that postinst.d will "do the job",
	it's not what might have been originally envisaged,
	but it's "close enough", and more importantly, it's
	actually been implemented (whereas #17243 wishlist
	item dates back SIX YEARS to 1998!)

 5) who else can i chase with a Big Stick?


> Scott
> -- 
> Have you ever, ever felt like this?
> Had strange things happen?  Are you going round the twist?


*blink*.  oh, it's a .sig. :)

Reply to: