dpkg and selinux

dpkg and selinux

[Luke Kenneth Casson Leighton]

i've just heard from scott remnant who kindly responded with a
description of how he envisages debian's "triggers" system to work.

*deep breath*.

for those people involved with this issue, i really must say this:

- please read this message carefully.
- please read all of it.
- if you don't understand, please ask for clarification.
- please, if you haven't the time to respect the above requests,
  please don't reply to any discussions on this issue until you
  can.
  
  i've gone to a lot of trouble to understand and then outline
  the issues involved (my thanks to scott for explaining
  "triggers"), and i really don't want to get into discussions
  with people who may not know what those issues are, and how
  they impact debian-selinux systems.

please respect these requests.

please also if you spot any errors in what i have outlined here,
in the descriptions, logic, reasoning or conclusions, please don't
sit there like a bloody lemon assuming that i know it all and am
so far up my own bottom that i won't appreciate being corrected:
far from it - i _need_ this issue to be resolved, so that it will
minimise _my_ efforts in having to maintain a linux distro.

the quicker it's resolved, the happier i will be, and the less often
i will have to write about this issue.

SO HELP - DON'T HINDER.

onward.


as i understand it, the debian "trigger" system is designed to
optimise, over a series of installations of multiple packages,
the number of calls to:

- ldconfig
- scrollkeeper-update
- update-menus
- update-modules
- update-modules.modutils

etc.

as an example, 80% of all debian postinst (post install) packages
on my computer result in the running of update-menus.

given that all these scripts do the same thing it's an O(N*M) overkill
problem that the proposed "trigger" system would alleviate to an
O(N) problem.

the proposed "trigger" system would replace all instances of ldconfig
in all debian postinst scripts with dpkg-trigger ldconfig, all instances
of scrollkeeper-update with dpkg-trigger scrollkeeper-update.

etc.

at the end of the dpkg run [of installing multiple programs] then the
"triggers" would be activated.

if a postinst script ABSOLUTELY HAD to run a trigger THERE AND THEN,
then there is a special proposed "dpkg-trigger-right-now" program
which does the trigger there-and-then (and presumably clears the
cache so that it's not re-run at the end of the dpkg run).


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.

this is subtly different from dpkg triggers, and the differences are
due to the different requirements of selinux.  YES it is necessary
to run the selinux postinst.d script on EVERY package.  YES it
is necessary to run it after every package's postinst script.

[it MIGHT be possible to postpone / delay the running of the
 selinux postinst.d script, which is why i am going to the trouble
 of writing this message: see later for more explanation ]


unfortunately, people unfamiliar with selinux don't quite
believe or understand quite how much is involved, and it differs
in subtle ways that the proposed dpkg "trigger" system as it
stands doesn't...  _quite_ fulfil.

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.

also, that the differences between policies for redhat, suse,
gentoo and debian are pretty minimal... but there _are_ differences,
and it's unmaintainable madness to have the policy files in
different places.


scott - and presumably the other debian package maintainers
who couldn't, unlike scott kindly did, find the time to inform
the selinux community nor refer the selinux community to any
documentation on this subject - believes that dpkg "triggers"
are sufficient for selinux's use.

i am endeavouring to either convince him otherwise, or to make
some suggestions which would allow the present or an equivalent
of the present /etc/dpkg/postinst.d/selinux script running
under russell's patched dpkg to successfully be replaced by
a dpkg "trigger".

dpkg "triggers" will ONLY work for selinux under these circumstances,
and i REALLY mean "only".

a) if the selinux dpkg "trigger" could guarantee to ALWAYS be run, not
   just be called from one or a few packages.  reason: ALL files
   installed by ALL packages must have their file contexts revamped,
   NOT just some.
   
   all files, in fact, that are listed by dpkg -L <packagename>

b) i think i am right in saying that debian "Pre-Depends"
   groupings will have to be respected: namely that it would be
   necessary AT THE LEAST to have the selinux dpkg "trigger" run
   on groups of packages separated at "Pre-Depends" boundaries.

   i also believe that i am right in saying that this would 
   probably have to be done for all dpkg triggers _anyway_ - NOT
   just the proposed selinux dpkg trigger.

   otherwise, you could end up with awful screw-ups where
   update-modules might not get run, and a "Pre-Dependent"
   package was _really_ relying on a particular module or
   module options being set, that sort of thing.

   or, scrollkeeper-update might not get run, such
   that a "Pre-Dependent" package which really needed
   scrollkeeper-update to succeed prior to moving on.... you
   get the picture.

c) if the dpkg "triggers" could receive the complete list of all package
names, then it is conceivable that this list of names could be
amalgamated by the dpkg trigger /usr/lib/dpkg/triggers/selinux...
something like this:

	#!/bin/sh
	#
	# receive list of package names, merge all file in all
	# said packages, run setfile on all said files.
	# blah.


	filelist=""
	for x in $*
	do
		filelist="$filelist `dpkg -L $x`"
	done

	filelist="echo $filelist | sort | uniq"

	echo $filelist | setfiles -q -s /etc/selinux/contexts/file_contexts

i realise that this is crap shellscript, i don't care, it demonstrates
the principle, namely that it merges the list of all files and
directories of all packages installed in a dpkg run, sorts them, uniques
them, and then jums then into setfiles.

this is about as optimal as it could get...

... the question is: is it enough?

what i mean is:

*1 is there an absolute requirement that the present
  /etc/dpkg/postinst.d/selinux script BE RUN at the
  end and ONLY IMMEDIATELY AT THE END of EVERY
  postinst script of EVERY package being installed?

or:

*2 is it sufficient, is it the case that it's okay, to
  just wait until the end of a dpkg run (respecting
  "Pre-Depends" groupings of course), to wait until ALL
  postinst scripts (of one or more "Pre-Depends" groups
  of course) are run and THEN to do the above [proposed]
  /usr/lib/dpkg/triggers/selinux script (more than once if there
  is more than one "Pre-Depends" grouping of course), receiving
  the list of all names of all packages just newly installed
  (in each "Pre-Depends" group of course)?

because if the latter, then as long as the proposed dpkg
"trigger" system _does_ pass the list of all package names, and
as long as the new dpkg "trigger" system _can_ be made to run
the selinux trigger _irrespective_ of whether a postinst script
asked for it to be run (in fact if a postinst script _does_
ask it to be run except via "dpkg-trigger-right-now selinux",
then an error should be raised!) then everything's hunky-dory.

and if it's _not_ okay, then unfortunately we must continue to insist
that dpkg have the postinst.d system.

or continue to maintain a fork of dpkg.

or request the ftp masters to accept the creation of an se-dpkg package
containing the forked version of dpkg.


my concern with the latter (*2) is that there would be dependency
problems due to file contexts not having been updated yet,
that are completely avoided by the /etc/dpkg/postinst.d/selinux
approach [run just after the package's postinst script is run].

... or is the problem i envisage avoided by the selinux domain
in which dpkg is run (and by breaking things down into "Pre-Depends"
groups).

this last bit is probably something that only russell, stephen,
dan and colin are likely to be able to answer: the interactions
and workings of the dpkg policy and its impact on how dpkg
operates is something that requires their expert knowledge.

l.

p.s. 

for those people not familiar with dpkg, "Pre-Depends" is a system which
forces a COMPLETE install of all "Pre-Depends" packages prior to
proceeding with the installation of a package with a "Pre-Depends"
requirement.

if you specify "Depends:" then what you are saying is that
dpkg can just run all the unpacks of all packages and all
dependencies (in any order), then run all postinsts of all
packages and all dependencies (basically in any order it likes).

this solves the issues of accidental circular dependencies by totally
avoiding the problem :)

"Pre-Depends" is the only way in which accidental circular dependencies
can have serious "broken debian system" consequences.

you so totally can't have circular "Pre-Depends" but you _can_ have two
packages "Depend" on _each other_: of course, you need to ensure that
the postinst scripts of the inter-dependent cross-"Dependent" packages
are _really_ okay with that, such that it doesn't matter what order
their postinst scripts are run in.

my concern with selinux is that if the file contexts haven't been set
up yet under such circumstances... well, you can imagine what might
happen: you end up with "access denied" errors to files and directories
that haven't had their permissions correctly set...


-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
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.

Re: dpkg and selinux

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 11872 bytes --]

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.
> 
> this is subtly different from dpkg triggers, and the differences are
> due to the different requirements of selinux.  YES it is necessary
> to run the selinux postinst.d script on EVERY package.  YES it
> is necessary to run it after every package's postinst script.
> 
This is the bit I still have trouble believing; I could claim that it is
necessary for ldconfig or scrollkeeper-update to run on EVERY page...
but that's just not true.

Why is it necessary for the selinux update to complete before the
processing of the next package is begun?

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?

Or does it not matter that the daemon is started before selinux
privileges/permissions are applied to its binary?

If that doesn't matter I don't see why it matters that the processing is
deferred until the end of the run.

> 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 am endeavouring to either convince him otherwise, or to make
> some suggestions which would allow the present or an equivalent
> of the present /etc/dpkg/postinst.d/selinux script running
> under russell's patched dpkg to successfully be replaced by
> a dpkg "trigger".
> 
I believe triggers really will work for what you want; if they don't
then here's two problems with postinst.d:

1) is there actually another use case for it that isn't solved by
   triggers?

2) if not, then it's a selinux-specific feature and actually worse than
   simply embedding knowledge of selinux into dpkg.

   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.)

> dpkg "triggers" will ONLY work for selinux under these circumstances,
> and i REALLY mean "only".
> 
> a) if the selinux dpkg "trigger" could guarantee to ALWAYS be run, not
>    just be called from one or a few packages.  reason: ALL files
>    installed by ALL packages must have their file contexts revamped,
>    NOT just some.
>    
>    all files, in fact, that are listed by dpkg -L <packagename>
> 
Another use case for this "always run" functionality is prelinking
binaries, or updating the updatedb/locate database.

> b) i think i am right in saying that debian "Pre-Depends"
>    groupings will have to be respected: namely that it would be
>    necessary AT THE LEAST to have the selinux dpkg "trigger" run
>    on groups of packages separated at "Pre-Depends" boundaries.
> 
Why?

If there really is this "policy must be in place before FOO" problem,
surely that (potentially) exists *inside* a single postinst.

In which case we're back to changing postinst of every package again
(which is actually largely just a change-debhelper problem, anyway).

>    i also believe that i am right in saying that this would 
>    probably have to be done for all dpkg triggers _anyway_ - NOT
>    just the proposed selinux dpkg trigger.
> 
>    otherwise, you could end up with awful screw-ups where
>    update-modules might not get run, and a "Pre-Dependent"
>    package was _really_ relying on a particular module or
>    module options being set, that sort of thing.
> 
You've made the very common mistake of mis-understanding how Pre-Depends
work, and how they differ for maintainer scripts compared to ordinary
Depends.  (postinst do run in Depends order, even without Pre-Depends).

Triggers are intended for the kind of postinst activity that can be run
en-masse at the end of the run because it isn't important for depending
packages.

Where importance is placed by depending packages, triggers are not
appropriate and using them would be an abuse (subject to note below).

>    or, scrollkeeper-update might not get run, such
>    that a "Pre-Dependent" package which really needed
>    scrollkeeper-update to succeed prior to moving on.... you
>    get the picture.
> 
This would never happen; scrollkeeper-update updates the database used
by the user's help browser.  Depending packages never care about it,
thus it's a perfect candidate for triggers.

The exception is where *usually* it's an en-masse activity, but there's
a special requirement that it be run for this package.  Your update-
modules example would be one, except that's deprecated anyway (module-
init-tools' modprobe reads /etc/modprobe.d anyway) -- the package would
ensure that any update-modules runs had been completed.  I actually
can't honestly think of use cases for this now, but there might be some.

> c) if the dpkg "triggers" could receive the complete list of all package
> names, then it is conceivable that this list of names could be
> amalgamated by the dpkg trigger /usr/lib/dpkg/triggers/selinux...
> something like this:
> 
I certainly don't see a problem with this.  We're wandering to classes
with this behaviour though <g>

What happens to those files the package's postinst creates?  Such as
debconf-maintained configuration files, symlinks, etc.  How do those get
selinux policy?

Aren't you going to need to modify the postinst to add policy for them
too?


> *1 is there an absolute requirement that the present
>   /etc/dpkg/postinst.d/selinux script BE RUN at the
>   end and ONLY IMMEDIATELY AT THE END of EVERY
>   postinst script of EVERY package being installed?
> 
If there is this requirement, I maintain there is probably a requirement
that it be run before the end of an individual postinst ... requiring
changes to the postinst.

Use case:  Mail server, started as per-policy in postinst.

Do you need to have the selinux policies for its queue and spool
directories in place before it starts?  If so you need to modify that
postinst to do the work before the invoke-rc.d call.

> *2 is it sufficient, is it the case that it's okay, to
>   just wait until the end of a dpkg run (respecting
>   "Pre-Depends" groupings of course), to wait until ALL
>   postinst scripts (of one or more "Pre-Depends" groups
>   of course) are run and THEN to do the above [proposed]
>   /usr/lib/dpkg/triggers/selinux script (more than once if there
>   is more than one "Pre-Depends" grouping of course), receiving
>   the list of all names of all packages just newly installed
>   (in each "Pre-Depends" group of course)?
> 
I don't believe you need this pre-depends grouping (see above).

> and if it's _not_ okay, then unfortunately we must continue to insist
> that dpkg have the postinst.d system.
> 
Which would have an entire feature for one particular subset of users,
leaving that feature open to abuse by the others; which I massively
dislike.

> or continue to maintain a fork of dpkg.
> 
> or request the ftp masters to accept the creation of an se-dpkg package
> containing the forked version of dpkg.
> 
These are the same thing, and there's no need to involve the ftpmasters.
I'm reasonably sure that anybody is free to upload competing package
managers, provided they don't stamp on the dpkg namespace (dpkg.*).

> my concern with the latter (*2) is that there would be dependency
> problems due to file contexts not having been updated yet,
> that are completely avoided by the /etc/dpkg/postinst.d/selinux
> approach [run just after the package's postinst script is run].
> 
Why would there be this problem?

> ... or is the problem i envisage avoided by the selinux domain
> in which dpkg is run (and by breaking things down into "Pre-Depends"
> groups).
> 
Why do we need to do this breaking-things-into-groups?

> for those people not familiar with dpkg, "Pre-Depends" is a system which
> forces a COMPLETE install of all "Pre-Depends" packages prior to
> proceeding with the installation of a package with a "Pre-Depends"
> requirement.
> 
> if you specify "Depends:" then what you are saying is that
> dpkg can just run all the unpacks of all packages and all
> dependencies (in any order), then run all postinsts of all
> packages and all dependencies (basically in any order it likes).
> 
*BZZZT* wrong!

Utterly, utterly, incorrect my friend.

Pre-Depends does require complete installation of a package has been
performed before the pre-depending package.  This means that the pre-
depended package will have been unpacked and configured (including
postinst) before the pre-depending package is even unpacked.

Depends requires that depended packages have been unpacked and
configured before depending packages are configured.  This means that
the packages may be unpacked in a reasonably random order, BUT THAT
CONFIGURATION HAPPENS *IN ORDER* (not "any order it likes").

To simplify:

  X Pre-Depends Y means that X.preinst happens *after* Y.postinst.

  X Depends Y means that X.postinst happens *after* Y.postinst.
  (but X.preinst might happen before Y.postinst).

> you so totally can't have circular "Pre-Depends" but you _can_ have two
> packages "Depend" on _each other_
> 
Actually this has more to do with the fact dpkg will break dependency
cycles introduced by Depend, but not by Pre-Depend.

> of course, you need to ensure that
> the postinst scripts of the inter-dependent cross-"Dependent" packages
> are _really_ okay with that, such that it doesn't matter what order
> their postinst scripts are run in.
> 
postinst are run in depend order; where there's a cycle that is still
true, they are run in the order they are depended on -- starting at a
given "sensible" point in the cycle.

descent foo% dpkg-deb -f test1_1_i386.deb | grep test
Package: test1
Depends: test2
descent foo% dpkg-deb -f test2_1_i386.deb | grep test
Package: test2

descent foo% sudo dpkg -i test1_1_i386.deb test2_1_i386.deb
Selecting previously deselected package test1.
(Reading database ... 144342 files and directories currently installed.)
Unpacking test1 (from test1_1_i386.deb) ...
Selecting previously deselected package test2.
Unpacking test2 (from test2_1_i386.deb) ...
Setting up test2 (1) ...
Setting up test1 (1) ...

The packages were unpacked in the order given, but the configuration was
done in the order required by the dependencies.


> my concern with selinux is that if the file contexts haven't been set
> up yet under such circumstances... well, you can imagine what might
> happen: you end up with "access denied" errors to files and directories
> that haven't had their permissions correctly set...
> 
Then I'm convinced this can happen within a given postinst; see my mail
server use case.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: dpkg and selinux

[Luke Kenneth Casson Leighton]

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.
> > 
> > this is subtly different from dpkg triggers, and the differences are
> > due to the different requirements of selinux.  YES it is necessary
> > to run the selinux postinst.d script on EVERY package.  YES it
> > is necessary to run it after every package's postinst script.
> > 
> This is the bit I still have trouble believing; 

 i really can't help you with what you believe.

 i know you do: it's why i keep repeating it in the hope that i can
 help.

 your difficulty in believing it isn't going to make any difference
 in affecting whether it's actually true or not.

 it's quite simple:
 
	any file or directory created by dpkg as it unpacks
	the package needs to have its selinux permissions
	"retrofitted", as laid down by a SITE ADMINISTRATOR's
	decision on what version and what type of policy to use.
	
	the decision made by the site administrator (not by the
	package maintainer and not by the NSA!) results in the
	generation of a "file contexts" file,
	/etc/selinux/contexts/file_contexts.

	that file contains "the equivalent" of chmod+chown+chgrp,
	with regexps to match the files+directories+symlinks that
	that equivalent of chmod+chown+chgrp should be applied to.

	e.g. i am running a "strict" policy, version 1.14 with
	some custom modifications, so i have, as an example,
	these:

	/bin(/.*)?                      system_u:object_r:bin_t
	/bin/tcsh               --      system_u:object_r:shell_exec_t
	/bin/ls                 --      system_u:object_r:ls_exec_t

	which means "everything in /bin (and including /bin the directory)
	except /bin/tcsh and /bin/ls get the file context 'bin_t".
	
	and:

	/etc(/.*)?                      system_u:object_r:etc_t
	/etc/mtab               --      system_u:object_r:etc_runtime_t

	where etc_t is typically kept read-only to most programs,
	and files of type etc_runtime_t are typically allowed to be
	be written to by certain programs that need to (init scripts,
	dpkg etc).
	


 ... i wrote you a detailed message last night, in which i
 outlined an analogy.

 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".

 there would not be a chance in hell of being able to "retrofit"
 chmod, chgrp and chown into postinst scripts: package maintainers
 would bitch like mad, and not understand it, and it would be
 unreasonable to expect them to understand it (think of retro
 converting 30 years of FAT filesystem usage to ext2!)

 and it would almost undoubtedly be expected that every file and
 directory created would need to be chmodded, chowned and chgrp'd,
 as a package was installed.

 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...
 
 ... just like there are in /etc/selinux/contexts/file_contexts
 (5972 lines in the case of my modified 1.14 policy)

 the scope and scale of the task and achievement of selinux is
 just... mind-boggling.

 it's just... so ambitious!! *gibber*.  retro-fitting a security
 model onto linux.  madness!

 ahem.  sorry.  calm, calm.


> I could claim that it is
> necessary for ldconfig or scrollkeeper-update to run on EVERY page...
> but that's just not true.
 
 and i can see for myself that it's not true.



> Why is it necessary for the selinux update to complete before the
> processing of the next package is begun?

 this is what i am not sure about.

 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)

 namely, that there are some libselinux functions that can be used
 to ensure that at file/dir CREATE time the correct selinux permissions
 will be applied, on a per-file, per-directory basis.

 the /etc/dpkg/postinst.d/selinux approach is the quickest and simplest
 way to achieve the desired results...

 ... it might be the case that there are flaws in it that will
 _require_ modifications to dpkg...  looking at the code,
 main.c around lines 529 etc. in the tarobject function.

 am i correct in thinking that the tarobject function is responsible
 for doing the dpkg unpacking?

 because if so, that's where the setfscreatecon() function calls to
 libselinux functions would be need to be done (as they are in
 udev, cron, star, and other packages).

 this would result in guaranteed atomic file/dir/symlink create
 operations that the /etc/dpkg/postinst.d/selinux ... "hack" just
 doesn't and can't do.



> 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 think only stephen, russell, dan or colin are in a position to
 answer that.

 hang on... in russell's postinst patch, what happens first.

 the package is unpacked, the /etc/dpkg/postinst.d/selinux script is
 run, the package's postinst script is run.

 [this is the one that makes sense]

 OR is it:

 the package is unpacked, the package's postinst script
 is run, the /etc/dpkg/postinst.d/selinux script is run.

 [this is the one that would suffer from the problems you outline
  above, scott]
 


> Or does it not matter that the daemon is started before selinux
> privileges/permissions are applied to its binary?

 yes, i think it does.

 _hope_fully russell's patched dpkg does the selinux postinst.d script
 _before_ running the package's postinst script.

 
> If that doesn't matter I don't see why it matters that the processing is
> deferred until the end of the run.

 well i too was hoping that it would be the case: it doesn't look
 like it will be.


> > 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, i am going to assume
 otherwise by rewriting your statement as i believe it should
 have been asked, pretend that you said that instead, and then
 answer that.

 this is what i believe you to have said, which "softens" the
 impact of what "you" are trying to say into a respectful joke.

> if i understand you correctly, then by the same logic, it could be
> argued that Package maintainers don't need, and don't even need to
> know about debconf templates, translations, debian policy, etc.

> surely, therefore, we should consider separating those out into
> separate packages too!

 *lol* :) not quite.

 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?

 
 a SITE ADMINISTRATOR may decide to:

 - apply the targetted policy, which allows users to do pretty much
   anything (respecting unix perms of course) and it restricts
   services.

 - not apply a policy at all, for testing purposes.

 - apply the "strict" policy, which even stops unauthorised users from
   doing "su -", and even stops administrators from starting and
   stopping services unless they go through a special procedure

 - write, and apply, THEIR OWN policy.

 now, in the case of the latter, you can't seriously be telling
 me that a site administrator's OWN policy files, which they
 have hacked up for a particular package and a particular
 requirement, should go into a debian package?

 and that a debian maintainer must include hundreds, maybe thousands
 of separate administrators' policy files, world-wide?

 it just can't happen.




> > i am endeavouring to either convince him otherwise, or to make
> > some suggestions which would allow the present or an equivalent
> > of the present /etc/dpkg/postinst.d/selinux script running
> > under russell's patched dpkg to successfully be replaced by
> > a dpkg "trigger".
> > 
> I believe triggers really will work for what you want; if they don't
> then here's two problems with postinst.d:
> 
> 1) is there actually another use case for it that isn't solved by
>    triggers?
> 
> 2) if not, then it's a selinux-specific feature and actually worse than
>    simply embedding knowledge of selinux into dpkg.
> 
>    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.


> > dpkg "triggers" will ONLY work for selinux under these circumstances,
> > and i REALLY mean "only".
> > 
> > a) if the selinux dpkg "trigger" could guarantee to ALWAYS be run, not
> >    just be called from one or a few packages.  reason: ALL files
> >    installed by ALL packages must have their file contexts revamped,
> >    NOT just some.
> >    
> >    all files, in fact, that are listed by dpkg -L <packagename>
> > 
> Another use case for this "always run" functionality is prelinking
> binaries, or updating the updatedb/locate database.

 yes.

 yes!

 well ... in order to be useful, both those two systems (prelink and
 updatedb) would need to be given a list of files removed and a list of
 files added, and to know what to do with them.

 
> > b) i think i am right in saying that debian "Pre-Depends"
> >    groupings will have to be respected: namely that it would be
> >    necessary AT THE LEAST to have the selinux dpkg "trigger" run
> >    on groups of packages separated at "Pre-Depends" boundaries.
> > 
> Why?
> 
> If there really is this "policy must be in place before FOO" problem,
> surely that (potentially) exists *inside* a single postinst.
 
 okay, looking at russell's patch, it looks like he's been smart
 enough to switch the ordering based on whether it's a pre or post
 script.

 it _looks_ like:

 - on post<something> , all scripts in /etc/dpkg/post<something>.d are run
   BEFORE  the package's post<something> script is run

 - on pre<something>, all scripts in /etc/dpkg/pre<something>.d are
   run AFTER ...


> 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.


> >    i also believe that i am right in saying that this would 
> >    probably have to be done for all dpkg triggers _anyway_ - NOT
> >    just the proposed selinux dpkg trigger.
> > 
> >    otherwise, you could end up with awful screw-ups where
> >    update-modules might not get run, and a "Pre-Dependent"
> >    package was _really_ relying on a particular module or
> >    module options being set, that sort of thing.
> > 
> You've made the very common mistake of mis-understanding how Pre-Depends
> work, 
 
 i'm happy to be corrected because i need to understand the issues.

> > c) if the dpkg "triggers" could receive the complete list of all package
> > names, then it is conceivable that this list of names could be
> > amalgamated by the dpkg trigger /usr/lib/dpkg/triggers/selinux...
> > something like this:
> > 
> I certainly don't see a problem with this.  We're wandering to classes
> with this behaviour though <g>
 
 yep :)

 all solutions welcome.

> 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.

 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?

 does dpkg -L not include debconf-maintained configuration files?


> Aren't you going to need to modify the postinst to add policy for them
> too?
> 
> 
> > *1 is there an absolute requirement that the present
> >   /etc/dpkg/postinst.d/selinux script BE RUN at the
> >   end and ONLY IMMEDIATELY AT THE END of EVERY
> >   postinst script of EVERY package being installed?
> > 
> If there is this requirement, I maintain there is probably a requirement
> that it be run before the end of an individual postinst ... requiring
> changes to the postinst.
> 
> Use case:  Mail server, started as per-policy in postinst.
> 
> Do you need to have the selinux policies for its queue and spool
> directories in place before it starts?  

 yes, definitely.

 [see above description of my forays into russell's patch: it's
  dealt with.  hopefully.  mostly.  ]

> If so you need to modify that
> postinst to do the work before the invoke-rc.d call.
> 
> > *2 is it sufficient, is it the case that it's okay, to
> >   just wait until the end of a dpkg run (respecting
> >   "Pre-Depends" groupings of course), to wait until ALL
> >   postinst scripts (of one or more "Pre-Depends" groups
> >   of course) are run and THEN to do the above [proposed]
> >   /usr/lib/dpkg/triggers/selinux script (more than once if there
> >   is more than one "Pre-Depends" grouping of course), receiving
> >   the list of all names of all packages just newly installed
> >   (in each "Pre-Depends" group of course)?
> > 
> I don't believe you need this pre-depends grouping (see above).
> 
> > and if it's _not_ okay, then unfortunately we must continue to insist
> > that dpkg have the postinst.d system.
> > 
> Which would have an entire feature for one particular subset of users,
> leaving that feature open to abuse by the others; which I massively
> dislike.
> 
> > or continue to maintain a fork of dpkg.
> > 
> > or request the ftp masters to accept the creation of an se-dpkg package
> > containing the forked version of dpkg.
> > 
> These are the same thing, and there's no need to involve the ftpmasters.
> I'm reasonably sure that anybody is free to upload competing package
> managers, provided they don't stamp on the dpkg namespace (dpkg.*).
> 
> > my concern with the latter (*2) is that there would be dependency
> > problems due to file contexts not having been updated yet,
> > that are completely avoided by the /etc/dpkg/postinst.d/selinux
> > approach [run just after the package's postinst script is run].
> > 
> Why would there be this problem?

 
> > ... or is the problem i envisage avoided by the selinux domain
> > in which dpkg is run (and by breaking things down into "Pre-Depends"
> > groups).
> > 
> Why do we need to do this breaking-things-into-groups?
> 
> > for those people not familiar with dpkg, "Pre-Depends" is a system which
> > forces a COMPLETE install of all "Pre-Depends" packages prior to
> > proceeding with the installation of a package with a "Pre-Depends"
> > requirement.
> > 
> > if you specify "Depends:" then what you are saying is that
> > dpkg can just run all the unpacks of all packages and all
> > dependencies (in any order), then run all postinsts of all
> > packages and all dependencies (basically in any order it likes).
> > 
> *BZZZT* wrong!
> 
> Utterly, utterly, incorrect my friend.
 
 *lol* :)

> Pre-Depends does require complete installation of a package has been
> performed before the pre-depending package.  This means that the pre-
> depended package will have been unpacked and configured (including
> postinst) before the pre-depending package is even unpacked.

 yes.

 that is what i understood this to be, i just wasn't able to articulate
 it clearly.


> Depends requires that depended packages have been unpacked and
> configured before depending packages are configured.  This means that
> the packages may be unpacked in a reasonably random order, BUT THAT
> CONFIGURATION HAPPENS *IN ORDER* (not "any order it likes").
>

 that i didn't know.  makes sense.

 thanks for responding to this scott: we'll get there, i'm sure.

 i'll write a summary message later, outlining some of the 
 problems you've highlighted.

 (e.g the symlinks-created-in-postinst scripts one)

 l.


--
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.

Re: dpkg and selinux

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 8113 bytes --]

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
script.
	
> 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
it.

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.


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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: dpkg and selinux

[Luke Kenneth Casson Leighton]

On Wed, Sep 01, 2004 at 02:30:03PM +0100, Scott James Remnant wrote:
> 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
> script.
 	
	that is my mistake: i had not analysed russell's code.

	for a dpkg function beginning with "pre", it's run at the end;
	for a dpkg function beginning with "post" e.g. postinst,
	it's run at the beginning.

	[selinux doesn't need a pre* thing btw.]


> > 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; 

 ah.  that's not _quite_ true: that's been catered for already.

 the file_contexts file is dynamically generated from what
 selinux policy files the site administrator decides to
 "enable".

 the site administrator must make a decision on what parts of the
 policy files are to be installed.

 i spend 10 minutes a month ago removing the selinux policy files
 for oh, gawd, tinydns, apache, openca, sendmail, and a whole stack
 of other things.

 it's good practice to do this: i just hadn't got round to it.

 in this way, an attacker can't go and install a package on your
 system and have it work, because the binaries will end up with
 no permissions to run correctly.



> and doesn't seem to cope
> well with differing policy for (e.g.) two binaries called 'ssh' which
> may have different requirements.

 that _is_ true - sort-of.

 under such circumstances, the site administrator would need to decide
 which of the 

 if someone installs dropbear rather than openssh, and someone has
 never written an selinux policy for dropbear before, then they would
 have to write one - and install it.


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

 welllll... not quite: it's just that there's no automated system in
 place (yet) to make any such assumptions, such that it is necessary
 for the site administrator to _manually_ go through the set of
 160 policy packages, deciding which ones to activate and which ones
 to deactivate.

 russell _has_ been putting "X-Debian-Packages: xdm, kdm, gdm, wdm"
 into the tops of e.g. the domains/programs/xdm.te policy file,
 presumably so that in the future an automated decision can be made.

> 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.

 inside dpkg it has to be then, because literally every postinst
 would need to ask for its file contexts to be redone.


> However I'm loath to embed specific selinux support into dpkg if it
> introduces extra dependencies, or causes problems for those not using
> it.
 
 1) fortunately, the only extra dependency will be libselinux1 which
    needs to be made "Required" such that cron, coreutils, logrotate,
	ssh etc. can use it.

 2) fortunately, the problem you mention has been catered for: there's
    a run-time callable function in libselinux1 called
	"is_selinux_enabled()".


> > 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).

 okay, then that means that:

 1a) the unpack in the temporary place needs to be done as if the file
    was to go into the root.

 1b) the move needs to be handled carefully to ensure that the
    selinux permissions are preserved

 OR:

 2) the linux kernel could be "prepped" by the functions in libselinux
     such that the correct file contexts be applied at move time (i think!)


 from a coding point of view, i believe it'd be easier to go with 1)
 because you have the information available inside tarobject() about
 whether the thing being unpacked is a file, directory or symlink.

 that is important to know because it can be used to reduce the amount
 of work that libselinux needs to do on the regexp lookups in
 /etc/selinux/contexts/file_contexts.


> > > 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>

 :)  i think they left it up to me, and by examining russell's patch
 i think i worked it out.

> Actually that was irony, I could try for sarcasm if you like <g>
 
 *lol*

> > 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.

 eek.

> > >    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
 
 [...]

> 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.
 
 [time to deal with getting from here to there with the least amount of
  work...]

> > > 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.

 so, inside dpkg it is, then.

> > > 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).

 oh dear.

 well, under most circumstances, i believe that can be catered for
 (with /etc/init.d/xfs creating /tmp/.font-unix being a notable
  exception).

 one particular way is that selinux has the equivalent of an
 enhanced setgid for directories (known as file_auto_trans).

 so, as long as a package has all its config files, temp files,
 run files in its own directory (e.g. /etc/cups, /var/state/cups,
 /var/run/cups) then it's possible to say, with a file_auto_trans
 statement, "if the cups daemon creates a file in the directory
 /var/spool/cups, then give it _these_ permissions".

 unfortunately you can't get any more fine-grained than that without
 actually embedding libselinux code into, say, cups.

 but fortunately, for _most_ purposes, this is sufficient.

 it's typically the packages that disobey the Debian Policy
 (or is it FHS policy) about creating per-package directories in
 /etc, /var/run, /var/spool, /var/tmp that have the problems
 (like /tmp/.font-unix)


 anyway.

 more later.

 l.


--
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.

Re: dpkg and selinux

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

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

> On Wed, Sep 01, 2004 at 02:30:03PM +0100, Scott James Remnant wrote:
> > However I'm loath to embed specific selinux support into dpkg if it
> > introduces extra dependencies, or causes problems for those not using
> > it.
>  
>  1) fortunately, the only extra dependency will be libselinux1 which
>     needs to be made "Required" such that cron, coreutils, logrotate,
> 	ssh etc. can use it.
> 
That rules that solution out, then.  I'm not going to add a dpkg
dependency on libselinux until selinux is the default (over chown/chmod/
etc.)

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: dpkg and selinux

[Luke Kenneth Casson Leighton]

On Wed, Sep 01, 2004 at 09:50:28PM +0100, Scott James Remnant wrote:
> On Wed, 2004-09-01 at 18:25 +0100, Luke Kenneth Casson Leighton wrote:
> 
> > On Wed, Sep 01, 2004 at 02:30:03PM +0100, Scott James Remnant wrote:
> > > However I'm loath to embed specific selinux support into dpkg if it
> > > introduces extra dependencies, or causes problems for those not using
> > > it.
> >  
> >  1) fortunately, the only extra dependency will be libselinux1 which
> >     needs to be made "Required" such that cron, coreutils, logrotate,
> > 	ssh etc. can use it.
> > 
> That rules that solution out, then.  

 ... temporarily.

> I'm not going to add a dpkg
> dependency on libselinux until selinux is the default (over chown/chmod/
> etc.)
 
 it's okay: the only reason that libselinux1 isn't presently "Required"
 is because of the sarge freeze...

 ... which brings us neatly back full circle as to why i contacted you
 last month to see if i could help in oxford :)

 l.


--
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.

Re: dpkg and selinux

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

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

>  ... which brings us neatly back full circle as to why i contacted you
>  last month to see if i could help in oxford :)
> 
My Debian work, including maintaining dpkg is very much done in my spare
time.  My job at Canonical doesn't currently have much to do with the
distribution itself, and we're not shipping with selinux in our first
release so it wouldn't have been something I could find the time for in
Oxford (which was manic for me as it was).

OTOH, I'm only just up the road in Birmingham anyway ...

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: dpkg and selinux

[Russell Coker]

On Thu, 2 Sep 2004 03:25, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>  russell _has_ been putting "X-Debian-Packages: xdm, kdm, gdm, wdm"
>  into the tops of e.g. the domains/programs/xdm.te policy file,
>  presumably so that in the future an automated decision can be made.

Colin Walters wrote such code, but I never got around to integrating it into 
the policy package.  I got too bogged down in writing policy and other SE 
Linux stuff.

> > 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.
>
>  inside dpkg it has to be then, because literally every postinst
>  would need to ask for its file contexts to be redone.

OK, same as has been done for rpm.

> > Vaguely, files are unpacked in a temporary place then moved into the
> > right place (inside process_archive).
>
>  okay, then that means that:
>
>  1b) the move needs to be handled carefully to ensure that the
>     selinux permissions are preserved

This is already catered for.  The only move which could lose the SE Linux 
context is one that crosses file systems.  This doesn't work for package 
installation anyway (imagine if /bin/bash or /usr/bin/perl was being replaced 
and half way through copying over the new file there was a power failure).

>  2) the linux kernel could be "prepped" by the functions in libselinux
>      such that the correct file contexts be applied at move time (i think!)

No kernel changes.

> > > > 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).

If the files are put into a directory that is specific to them then it's easy 
to sort out the context as Luke notes below.  Otherwise something like the 
following in a postinst script will work:
test -s /sbin/restorecon && /sbin/restorecon $CONFFILE

>  well, under most circumstances, i believe that can be catered for
>  (with /etc/init.d/xfs creating /tmp/.font-unix being a notable
>   exception).

test -s /sbin/restorecon && /sbin/restorecon /tmp/.font-unix

>  one particular way is that selinux has the equivalent of an
>  enhanced setgid for directories (known as file_auto_trans).
>
>  so, as long as a package has all its config files, temp files,
>  run files in its own directory (e.g. /etc/cups, /var/state/cups,
>  /var/run/cups) then it's possible to say, with a file_auto_trans
>  statement, "if the cups daemon creates a file in the directory
>  /var/spool/cups, then give it _these_ permissions".
>
>  it's typically the packages that disobey the Debian Policy
>  (or is it FHS policy) about creating per-package directories in
>  /etc, /var/run, /var/spool, /var/tmp that have the problems
>  (like /tmp/.font-unix)

I think that /var/run/.font-unix would be better anyway.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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.

Re: dpkg and selinux

[Luke Kenneth Casson Leighton]

On Tue, Sep 07, 2004 at 10:20:53PM +1000, Russell Coker wrote:

> > > Vaguely, files are unpacked in a temporary place then moved into the
> > > right place (inside process_archive).
> >
> >  okay, then that means that:
> >
> >  1b) the move needs to be handled carefully to ensure that the
> >     selinux permissions are preserved
> 
> This is already catered for.  The only move which could lose the SE Linux 
> context is one that crosses file systems.  This doesn't work for package 
> installation anyway (imagine if /bin/bash or /usr/bin/perl was being replaced 
> and half way through copying over the new file there was a power failure).
 
 so... if i have /usr, /var, / and /boot on separate partitions, and move
 files around, is the selinux context lost or kept?





> >  2) the linux kernel could be "prepped" by the functions in libselinux
> >      such that the correct file contexts be applied at move time (i think!)
> 
> No kernel changes.
 
 [i mean by using libselinux1 in standard way]

> >  well, under most circumstances, i believe that can be catered for
> >  (with /etc/init.d/xfs creating /tmp/.font-unix being a notable
> >   exception).
> 
> test -s /sbin/restorecon && /sbin/restorecon /tmp/.font-unix

 (in /etc/init.d/xfs i've used if [ -x /sbin/restorecon ]; then /sbin....
  but hey it's all the same)

  l.


--
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.

Re: dpkg and selinux

[Russell Coker]

On Tue, 7 Sep 2004 22:39, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > This is already catered for.  The only move which could lose the SE Linux
> > context is one that crosses file systems.  This doesn't work for package
> > installation anyway (imagine if /bin/bash or /usr/bin/perl was being
> > replaced and half way through copying over the new file there was a power
> > failure).
>
>  so... if i have /usr, /var, / and /boot on separate partitions, and move
>  files around, is the selinux context lost or kept?

It's kept by default with the modified coreutils.  Other programs that perform 
similar functions to mv will operate differently.

> > >  2) the linux kernel could be "prepped" by the functions in libselinux
> > >      such that the correct file contexts be applied at move time (i
> > > think!)
> >
> > No kernel changes.
>
>  [i mean by using libselinux1 in standard way]

Yes, we can make dpkg call functions in libselinux1.

> > >  well, under most circumstances, i believe that can be catered for
> > >  (with /etc/init.d/xfs creating /tmp/.font-unix being a notable
> > >   exception).
> >
> > test -s /sbin/restorecon && /sbin/restorecon /tmp/.font-unix
>
>  (in /etc/init.d/xfs i've used if [ -x /sbin/restorecon ]; then /sbin....
>   but hey it's all the same)

Yes.  Now we just need to get that into the init script.  Please file an 
appropriate bug report requesting that either method be used.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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.

Re: dpkg and selinux

[Luke Kenneth Casson Leighton]

On Wed, Sep 08, 2004 at 11:32:36PM +1000, Russell Coker wrote:

> > > >  well, under most circumstances, i believe that can be catered for
> > > >  (with /etc/init.d/xfs creating /tmp/.font-unix being a notable
> > > >   exception).
> > >
> > > test -s /sbin/restorecon && /sbin/restorecon /tmp/.font-unix
> >
> >  (in /etc/init.d/xfs i've used if [ -x /sbin/restorecon ]; then /sbin....
> >   but hey it's all the same)
> 
> Yes.  Now we just need to get that into the init script.  Please file an 
> appropriate bug report requesting that either method be used.

 done.

--
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.

Re: dpkg and selinux

[Russell Coker]

On Wed, 1 Sep 2004 23:30, Scott James Remnant <scott@netsplit.com> wrote:
> 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.

The problem with that idea is that there are many possible policies.  Fedora 
currently has two significantly different policies which require different 
file labels on disk.  Storing the data in the package for such things is not 
going to work (and would require that all DDs have some SE Linux files 
installed on their systems).

The right solution is to apply the regex set at install time.

> 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.

Only one binary can have the full path /usr/bin/ssh which is what matters.

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

Getting it to work in Debian should not be difficult.  Having a shared object 
interface to make the SE Linux library a plug-in and thus support RSBAC etc 
also shouldn't be too difficult.

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

No, I've just been busy recently.  I've got about 1600 messages to catch up on 
at the moment...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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.

Re: dpkg and selinux

[Luke Kenneth Casson Leighton]

a summary follows of the discussions of dpkg between scott and myself
(my thanks to scott for taking the time to read what i wrote yesterday,
 and for responding).

- dpkg needs in some way to set up the selinux file contexts of each
  and every file, directory, symlink and inode of a package it installs.

  if it does not do this, the default permissions are likely to be
  incorrect, such that the program is highly unlikely to work.

- russell's "postinst.d" patch is _one_ way to achieve this desired
  result: after files are unpacked, the list of files / directories
  of the package is taken and the selinux contexts are set on all
  those files and directories.

- dpkg "postinst" scripts, or more likely the /etc/init.d/* startup
  scripts MAY, in some unlikely cases, need to be modified to set
  permissions on files, directories or symlinks that they create
  INSIDE the "postinst" script or INSIDE their /etc/init.d/XXXX
  script.

  such modifications have, to date, found to be extremely rare.

  one recent example is, however, /etc/init.d/xfs which creates
  the directory /tmp/.font-unix and it is necessary to use
  restorecon to reset the permissions correctly on that directory.

- the proposed dpkg "trigger" system which scott kindly explained is
  an optimisation of the number of times that things like
  scrollkeeper-update, ldconfig, update-menus etc are called by
  package postinst scripts, to reduce these down to the absolute
  minimum [zero or one, at the end of a dpkg run].

- the dpkg "trigger" design would have to be stretched in order to
  fit selinux in, but should that be done, the resultant design
  could then also deal with "updatedb / locate" and other things
  that need to know what files a package has added or removed from
  a debian system.

- russell's "postinst.d" system is sufficiently confusingly similar
  to "triggers" such that it could end up being abused.

consequently, in short, it's probably best to patch dpkg's
"tarobject()" function to set the SE/Linux file permissions,
and to have those permissions preserved as the unpacked
archive is then moved into place.

l.

-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
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.

Re: dpkg and selinux

[Russell Coker]

On Thu, 2 Sep 2004 03:47, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> consequently, in short, it's probably best to patch dpkg's
> "tarobject()" function to set the SE/Linux file permissions,
> and to have those permissions preserved as the unpacked
> archive is then moved into place.

That's probably correct.  Code contributions are welcome...

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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.