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

Re: dpkg and selinux

On Wed, 2004-09-01 at 11:19 +0100, Luke Kenneth Casson Leighton wrote:

> On Wed, Sep 01, 2004 at 03:12:42AM +0100, Scott James Remnant wrote:
> > On Wed, 2004-09-01 at 00:41 +0100, Luke Kenneth Casson Leighton wrote:
> > 
> > > the way that russell's "postinst.d" patch works is that for every
> > > package, exactly at the end of its postinst script, the scripts in
> > > postinst.d are run - with the name of the package as an argument.
So we've ascertained that this statement was wrong and that Russell's
patch actually runs postinst.d scripts *before* the package's postinst
> the analogy is to imagine that chmod, chgrp and chown were a new
> concept that had to be retrofitted onto a system where the default
> permissions were noaccess, noaccess, 0000, with no members in the
> group "noaccess".
It's an interesting one, certainly I'd suggest the right solution would
be to do such commands in postinst until such time as it was the default
and the tar format could carry this information.  It would then become
policy that it would be carried inside the tar file, just as chmod/
chgrp/chown are carried today.

> you'd have to specify a file with unix_contexts in it which
> had:
>  	/bin(/.*)?		root,root,0755
> 	/bin/ping		root,root,1755 (...or is it 3755 for setuid?)
> etc, with THOUSANDS of entries...
The thing that worries me about this file is that it contains policy for
things I don't have installed on my system; and doesn't seem to cope
well with differing policy for (e.g.) two binaries called 'ssh' which
may have different requirements.

SELinux's seems to suffer the same problem, it assumes what you have
installed on your system.

Ordinary system administrators don't want this file, they want a
sensible chown/chgrp/chmod setup when they install packages -- how many
of our users really use dpkg-statoverride?

> it might not actually be the case... but the example you give below
> tends to suggest that it might be worse than suspected, and
> that the source code of dpkg might need to be patched instead,
> in the same way that rpm has been patched (and cron, and ssh,
> and udev)
Indeed, I'm leaning towards agreeing with you.  The postinst solution
has always smelled of rotten fish, it needs to be done properly --
either inside dpkg or inside the package postinsts.

However I'm loath to embed specific selinux support into dpkg if it
introduces extra dependencies, or causes problems for those not using

The fact that RPM does it isn't actually relevant; RPM has a history of
doing things at install-time ... e.g. library/file dependencies.  We've
always taken a build-time attitude to it, with the packaging format and
manager as (relatively) simple as possible.

> am i correct in thinking that the tarobject function is responsible
> for doing the dpkg unpacking?
Vaguely, files are unpacked in a temporary place then moved into the
right place (inside process_archive).

> > If it's really true, isn't it going to be also true that sometimes you
> > need to do the selinux processing before certain actions in the postinst
> > (like starting the daemon) are performed?
> ... you know, i think you could be right.
I knew I wasn't crazy :o)

> i think only stephen, russell, dan or colin are in a position to
> answer that.
Sadly they've stopped answering my calls <g>

> > > for example, a few months ago i genuinely believed that
> > > it would be a great idea for all package maintainers to be
> > > responsible for selinux policy (such that it would be okay to
> > > move selinux policy into debian packages): now i know that there
> > > are targetted and strict policies, and that writing selinux
> > > policy is sufficiently complex and inter-dependent for it to
> > > require significant expert knowledge - something that package
> > > maintainers DON'T NEED and DON'T even NEED TO KNOW ABOUT.
> > > 
> > Package maintainers don't need, and don't even need to know about
> > debconf templates, translations, debian policy, etc.  Let's separate
> > those out into separate packages too!
> i know you mean that in a sarcastic way
Actually that was irony, I could try for sarcasm if you like <g>

> okay... an analogy that may help you to understand: how many versions
> of the debian policy document are there?
> there's only one, isn't there?  everyone stick to it (hmmm, please
> don't correct me if that's wrong :)
>  ... what if there was more than one debian policy document?
>  what if SITE ADMINISTRATORS could decide which debian policy document
>  should be applied to their system?
>  as a concept, it doesn't work, does it?
Actually, it rather does.  Site admins could specify where man pages
went on their system, how shared libraries were installed, etc.

> >    And here we lead on to another fairy-tale story of "classes", a
> >    feature of Solaris' packaging system I quite admire.  The selinux
> >    support packages could implement replacement class handling that
> >    performed the required selinux voodoo as it installed files.
> > 
> >    (This is one of my ideas for generic conffile handling, btw.)
> ooooo.
> well, replacement, no, but "wrapping" yes.
> in other words, the selinux support packaging system would run and then be
> responsible for calling the "default" packaging system.
Yeah.  The basic theory of a class is that it's a function responsible
for taking an unpacked item (if it exists) and placing it on the
filesystem in the right place (with diverts taken into account).
conffiles would just be files with a different class to ordinary files
that offered a chance to choose which file won.

You could then specify alternate handlers for a class, dropping in
(e.g.) a debconfish or ucf replacement for the default configuration
handling, one that did a 3diff, etc.

SELinux could replace the default class handler with one that applied
contexts after the default was run.

But as I said, this is fairy-land at the moment -- it's a feature of
Solaris' packaging system I admire, and would certainly make some of the
code more generic and less twisty.

> > Another use case for this "always run" functionality is prelinking
> > binaries, or updating the updatedb/locate database.
> yes.
Notably though these are "always run at the end of an installation run",
so aren't compatible with the stuff you've asked for.

> > In which case we're back to changing postinst of every package again
> > (which is actually largely just a change-debhelper problem, anyway).
> well, if the same effect can be achieved by doing the equivalent in
> debhelper, then great.
Certainly, debhelper writes the stuff to postinst for a large percentage
of our packages.  It's a build-time solution to the problem, and
relatively elegant.

> > What happens to those files the package's postinst creates?  
> > Such as
> > debconf-maintained configuration files, symlinks, etc.  How do those get
> > selinux policy?
>  to be honest, i don't rightly know.
>  _hopefully_ they are mentioned in the dpkg -L <packagename> listing
>  such that they can be managed.
Nope.  Policy, in fact, demands that they aren't mentioned -- files
written during package maintainer scripts *cannot* be dpkg managed
conffiles.  (They get into a bit of a fight).

>  i assume that if they're not listed in the dpkg -L <packagename>
>  listing that that's a bug in the package, because when the time
>  comes for that package to be purged, symlinks would be left behind.
>  .... or, is there something that's been missed?
The symlinks, files, etc. get removed in prerm.

> does dpkg -L not include debconf-maintained configuration files?
Yup, they're utterly missing from it.

descent scott% dpkg -S /etc/X11/XF86Config-4
dpkg: /etc/X11/XF86Config-4 not found.

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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: