|
Home > Archive > Debian Developers > June 2004 > [SE/Linux] status / progress report 13jun2004
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[SE/Linux] status / progress report 13jun2004
|
|
| Luke Kenneth Casson Leighton 2004-06-13, 5:51 pm |
| This is a status / progress report for Debian / SE/Linux integration.
I look forward to the day when it need no longer be maintained,
which will be when all of the outstanding issues have been addressed.
The constant work-in-progress version of this report will always be
available from:
http://hands.com/~lkcl/selinux
The major outstanding issues are:
* debian kernels need to be available compiled with se/linux security
enabled (and boot-time optional) by default. this results in a
2% performance hit (wow big deal) when se/linux is not enabled
at boot time. Gentoo, SuSE and Fedora all accept this 2%.
* sarge freeze is holding back libselinux1 from being made "Required"
which is holding pretty much evveerrything up, but there is a
temporary idea (do a package se-<pkgname> ) as a workaround.
* a decision needs to be made on dpkg either to accept the postinst.d
idea or come up with a workable alternative. decision appears to
be held up because people "don't like the idea of selinux" rather
than for any genuine technical reason.
"alternative" patched dpkg package that provide the postinst.d
functionality will be made available "ad infinitum" until a
decision is made.
... how about an se-dpkg? maybe the se_apt-get, se_dpkg,
se_dpkg-reconfigure scripts could be moved into it, at the
same time?
* the idea of using a pam_selinux.so for everything has been disrupted
slightly for certain packages such as kdm, openssh, because the
ordering of opening ttys and calling the pam session stuff tends
to be moved about by upstream developers - without consideration
as to the impact it will have. pre-pam_selinux patches (esp. for
openssh) have been "dusted off".
* pam seems to have "lost the plot" a bit and serious consideration
is being given to doing a fork for BOTH redhat AND debian.
[the debian pam maintainer has a staggering FIFTY upstream
patches in debian/patches/ for 0.77. he's prepared to accept
ANOTHER patch to add to the list, for selinux, but only
against latest cvs - 0.78 or above. redhat also have to
maintain their own patches - against 0.76 - which includes
bug fixes that aren't in the "alternative" debian packages
yet, and it's all just going pear-shaped]
packaging:
* "alternative" unstable packages (which had had to be patched,
see individual status reports below) for:
coreutils, cron, dpkg, init, kern, logrotate and pam
are all available from http://selinux.lemuria.org/newselinux
(or from the original http://www.coker.com.au/newselinux)
* "standard", or "default" packages for unstable (sid)
selinux-policy-default, selinux-utils, libselinux1,
checkpolicy, policycoreutils and selinux-doc
are available from the debian mirrors - current versioning
is 1.12-2 to 1.12-3 of these packages.
NSA/SELinux kernel 2.6:
http://www.nsa.gov/selinux/code/download5.cfm
http://sf.net/projects/selinux/ (see cvs).
status: most of the selinux enhancements are available
upstream in 2.6, however the very latest patches
are only available from the above sites.
debian:
http://lists.debian.org/debian-deve...5/msg01738.html
status: presently, base packages are frozen and no modifications
or additional packages are allowed (to base). this
affects libselinux1 status from being changed, and therefore
pretty much everything else from thereon down.
temporary measure idea for maintainers is to produce
"se-pkgname" which will later on be an empty package
depending on "pkgname".
debian kernel 2.6 images:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249510
http://open.hands.com/~lkcl/selinux
status: raised only 12 days ago. requested that se/linux
security config options be enabled in stock
Debian kernels but require selinux=1 and enforcing=1
to switch it on.
coreutils:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193328
status: 1 year old, requested information, information now
provided, upstream and maintainer prodded for
acknowledgement. [30may2004] mike stone responded
by saying that it's unlikely that action will be taken
until after sarge is released.
logrotate:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224880
status: russell alerted maintainer that upstream inclusion
is done (157 days ago) but debian package 3.7-1
disables it by default due to libselinux1 not being
"base/required" or "important". change made to
libselinux1 to reflect that.
[30may2004] paul martin confirmed that he is waiting
for this change, and the "ftpmasters" need to make
the decision.
13jun2004: pinged paul suggesting the se-<pkgname>
idea.
cron:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644
i think this one's my favourite.
status: 1 year old. bit of a wing-ding and misunderstanding
over a field name, fortunately the maintainer stood
his ground until the non-cron-code-experts understood
the issues. updated patch sent.
31may2004: steve (maintainer) evaluating patch. also
steve aware of sarge freeze and implications.
8jun2004: bug found in cron which was accidentally
fixed in selinux version. steve (maintainer) now
happy. to check / confirm latest patch with sds (nsa)
8jun2004: steve to create a cron and se-cron package
where se-cron will be a dummy package when sarge
is released (and libselinux1 goes to "Required").
10jun2004: dan walters created new patch, with some
additional cleanups etc. sent to steve (maintainer)
pam:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249499
http://www.redhat.com/archives/pam-...y/msg00058.html
status: amazingly, only 19 days old. unless there's an
earlier one and it's already been integrated
upstream. changes are only to pam_unix, apparently,
on that one (and there's another patch for pam_selinux).
information sought from upstream and from the
maintainer.
30may2004: several messages to upstream explaining
that pam_selinux.so is needed upstream before
other packages can start putting
"session required pam_selinux.so" into upstream
as well.
30may2004: subscribed direct to list to avoid
moderation and wrote message explaining situation
(pam upstream acceptance or lack of equals major
hold-up).
1jun2004: issue with packages opening and closing
sessions, plus upstream packages moving the place
where pam is called from (e.g. openssh) causing
tty problems. serious consideration being given
to reinvoking / dusting-off the selinux patches that
pam_selinux was supposed to do away with, on the
basis that upstream authors are less likely to
interfere with the ordering of "#ifdef WITH_SELINUX"
than they are with moving calls to pam_open_session.
8jun2004: situation with pam is bad: no communication
whatsoever received from upstream. bugs in 0.76 fixed
for fedora, too much work to back-port. serious
consideration being given to forking pam. debian
maintainer happy to accept patch against latest sf.net
cvs (0.78 or above)
dpkg:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249496
http://lists.debian.org/debian-dpkg...3/msg00154.html
http://lists.debian.org/debian-deve...3/msg02063.html
http://lists.debian.org/debian-dpkg...5/msg00255.html
http://lists.debian.org/debian-deve...6/msg00698.html
status: mr russell coker's postinst.d patch is apparently
well-known and the bugreport has been merged with
other bugs, one of which (#17243) dates back to
1998! kuudosss. however, the maintainer says that
those bugs are part of a larger picture of
required / requested functionality and they don't
want to proceed with what would turn out to be a
temporary measure.
30may2004: after evaluating options (see links
above) initiated thread to convince dpkg
developers to incorporate postinst.d patch.
13jun2004: no response yet received, another ping
initiated.
init:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=242900
status: raised 50 days ago. seeking information from
debian maintainer.
13jun2004 contact. advised maintainer of
se-cron idea pending sarge unfreeze, suggested
doing an se-init (se-sysvinit), temporarily.
openssh:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193664
status: 30may2004 - russell's explained that this patch is no
longer needed because the patches to PAM deal with
this, now.
8jun2004 - serious consideration being given to
requesting the (retired) openssh WITH_SELINUX
patch be added due to calls to pam_open_session
having been moved to before ttys are set up
(in sshd). it's all gone pear-shaped.
10jun2004: investigation by dan and russell leads
to a decision to reintroduce the former openssh patch,
the one that didn't need pam_selinux, and to drop
pam_selinux in openssh.
star, procps, util-linux, shadow, vixie-cron:
status: although patches are available from
http://www.nsa.gov/selinux/code/download5.cfm,
no bug-report or integration into debian/selinux have
been initiated for these packages.
colin walters does have debian packages available
(mirrored at http://selinux.lemuria.org/walters)
login:
status: what used to be a patch in login can be achieved
equally well with pam_selinux.so session.
TODO: must write patch for kdm's /etc/pam.d/kdm to have
pam_selinux.so session required
kdm:
status: patch created to do context switch but due to the
design of kdm's backend the use of pam_selinux.so
session achieves the same goal, making patching kdm
unnecessary.
TODO: must write patch for kdm's /etc/pam.d/kdm to have
pam_selinux.so session required
wdm:
status: patch created but not yet accepted upstream. code
in wdm needs to be evaluated to see if pam_selinux.so
session will do the same job.
gdm:
status: patch accepted upstream to do session management.
it was essential in gdm that this be done because
the process doing authentication is separated from
the process doing the program running: pam_selinux.so
session would therefore be insufficient [without a
rewrite of gdm?]
xdm:
status: not known [to me].
libselinux:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251749
status: still at priority "optional". 30may2004 message sent
to debian-devel requesting assistance in alerting
the "ftpmasters" to the issue. response: russell
should have received a notification because ftp.debian.org
automatically "overrides" the priority.
postfix:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253732
status: the postfix policy requires that you disable chrooting
in order for postfix to work. 253732 is a wish-list
requesting an extra dpkg config question advising people
to select "no i do not want to chroot" if they are
installing on an se/linux system.
--
--
Information I post is with honesty, integrity, and the expectation that
you will take full responsibility if acting on the information contained,
and that, should you find it to be flawed or even mildly useful, you
will act with both honesty and integrity in return - and tell me.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Christoph Hellwig 2004-06-13, 5:51 pm |
| On Sun, Jun 13, 2004 at 03:36:48PM +0000, Luke Kenneth Casson Leighton wrote:
> * debian kernels need to be available compiled with se/linux security
> enabled (and boot-time optional) by default. this results in a
> 2% performance hit (wow big deal) when se/linux is not enabled
> at boot time. Gentoo, SuSE and Fedora all accept this 2%.
It's actually disabled again (compiled in but disabled) in SuSE because
the performance hit was much much worse. And I remember benchmark
numbers where the lsm hooks alone decreased the SpecWeb numbers on ia64
by more than 10%. I'd vote strongy against enabling LSM in the Debian
kernel images.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andres Salomon 2004-06-13, 5:51 pm |
| On Sun, 13 Jun 2004 15:36:48 +0000, Luke Kenneth Casson Leighton wrote:
[...]
>
> The major outstanding issues are:
>
[...]
>
> * a decision needs to be made on dpkg either to accept the postinst.d
> idea or come up with a workable alternative. decision appears to be
> held up because people "don't like the idea of selinux" rather than for
> any genuine technical reason.
>
> "alternative" patched dpkg package that provide the postinst.d
> functionality will be made available "ad infinitum" until a decision is
> made.
>
[...]
>
> dpkg:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249496
> http://lists.debian.org/debian-dpkg...3/msg00154.html
> http://lists.debian.org/debian-deve...3/msg02063.html
> http://lists.debian.org/debian-dpkg...5/msg00255.html
> http://lists.debian.org/debian-deve...6/msg00698.html
>
> status: mr russell coker's postinst.d patch is apparently
> well-known and the bugreport has been merged with
> other bugs, one of which (#17243) dates back to 1998! kuudosss.
> however, the maintainer says that those bugs are part of a larger
> picture of required / requested functionality and they don't want to
> proceed with what would turn out to be a temporary measure.
>
> 30may2004: after evaluating options (see links above) initiated thread
> to convince dpkg developers to incorporate postinst.d patch.
>
> 13jun2004: no response yet received, another ping initiated.
>
[...]
Wow. This sounds like a horrible idea. The fact that rpm does it,
doesn't make it any better; I've had redhat machines that corrupt their
rpm database every 3 or 4 rpm installs/upgrades (let's hear it for
libdb4).
If I understand the proposed patch correctly, a package installs a
postinst script that is run w/ every installed package's postinst script.
If this postinst script breaks, it makes every package on the system
uninstallable. Please tell me that this isn't the case. If the postinst
script takes a while to run, this significantly slows down installation of
all packages. This scheme is just begging for abuse by a maintainer.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andrew Suffield 2004-06-13, 11:49 pm |
| On Sun, Jun 13, 2004 at 04:43:21PM -0400, Andres Salomon wrote:
> If I understand the proposed patch correctly, a package installs a
> postinst script that is run w/ every installed package's postinst script.
> If this postinst script breaks, it makes every package on the system
> uninstallable. Please tell me that this isn't the case.
And in fact, the first usage of it (selinux) did precisely that for
quite some time, making every package on the system uninstallable if
you tried installing selinux-policy-default (#224919).
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
| |
| GOTO Masanori 2004-06-13, 11:49 pm |
| At Sun, 13 Jun 2004 19:01:46 +0200,
Christoph Hellwig wrote:
> On Sun, Jun 13, 2004 at 03:36:48PM +0000, Luke Kenneth Casson Leighton wrote:
>
> It's actually disabled again (compiled in but disabled) in SuSE because
> the performance hit was much much worse. And I remember benchmark
> numbers where the lsm hooks alone decreased the SpecWeb numbers on ia64
> by more than 10%. I'd vote strongy against enabling LSM in the Debian
> kernel images.
If it's true, I agree that we don't enable it in default.
Regards,
-- gotom
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-06-14, 5:53 pm |
| On Mon, 14 Jun 2004 03:01, Christoph Hellwig <hch@lst.de> wrote:
> On Sun, Jun 13, 2004 at 03:36:48PM +0000, Luke Kenneth Casson Leighton=20
wrote:
>
> It's actually disabled again (compiled in but disabled) in SuSE because
> the performance hit was much much worse. And I remember benchmark
> numbers where the lsm hooks alone decreased the SpecWeb numbers on ia64
> by more than 10%. I'd vote strongy against enabling LSM in the Debian
> kernel images.
In other distributions more features are enabled by default to reduce the=20
support costs (people will install the wrong kernel package and file bug=20
reports). In Debian choices are offered for everything, there are several=
=20
mail servers, several POP servers, having several builds for the kernel is=
=20
not a big deal.
Currently there has not been a large demand for SMP SE Linux kernels. So=20
adding a new kernel binary package that's the same as the default one for t=
he=20
most common CPU but with SE Linux enabled should be easy enough to do.
1-386 1-586tsc 1-686 1-686-smp 1-k6 1-k7 1-k7-smp speakup alpha amiga arm=20
atari bvme6000 hppa i386 ia64 mac mvme147 mvme16x q40 s390
=46rom a quick grep of the packages list the above seems to be the list of=
=20
supported Debian kernel binary packages. Adding a 686-selinux package and=
=20
compelling anyone who wants SE Linux on anything other than a 686 single-CP=
U=20
machine to compile their own kernel should make most people reasonably happ=
y. =20
Athlon's generally run i686 code well.
The architectures listed are for 2.4.x kernels - not all architectures supp=
ort=20
2.6.x yet. I suggest that Debian not provide any binaries to support 2.4.x=
=20
SE Linux kernels, it's just too much work to keep them maintained. I have=
=20
been thinking of requesting that my package kernel-patch-2.4-lsm be removed=
=20
from Debian as it usually takes more than a month for me to catch up with a=
=20
new kernel.org release.
I don't have the time to build such kernel binaries though, so someone else=
=20
will have to volunteer.
=2D-=20
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
| |
| Russell Coker 2004-06-14, 5:53 pm |
| On Mon, 14 Jun 2004 06:43, Andres Salomon <dilinger@voxel.net> wrote:
>
> Wow. This sounds like a horrible idea. The fact that rpm does it,
[...]
> If I understand the proposed patch correctly, a package installs a
> postinst script that is run w/ every installed package's postinst script.
> If this postinst script breaks, it makes every package on the system
> uninstallable. Please tell me that this isn't the case. If the postinst
> script takes a while to run, this significantly slows down installation of
> all packages. This scheme is just begging for abuse by a maintainer.
With my current implementation a slow script will slow down the system, and a
script that breaks will prevent all package's from completely installing.
For SE Linux the behaviour on a broken script does not cause a problem,
installing files without the correct SE Linux labels will break the entire
system so it's best to stop early.
Why is that scheme begging for abuse? If it gets abused then the package
which does so gets grave bug reports filed against it and does not progress
into testing.
The alternative to this is to patch dpkg with SE Linux support in the way that
rpm has been. Should I implement the needed functionality in that manner?
--
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
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2004-06-14, 5:53 pm |
| On Mon, Jun 14, 2004 at 05:40:05PM +1000, Russell Coker wrote:
> The alternative to this is to patch dpkg with SE Linux support in the
> way that rpm has been. Should I implement the needed functionality in
> that manner?
I would suggest that. SE Linux is an exception in that it needs to
update file system attributes for /any/ installed package. Creating too
generic solutions to such highly exceptional situations seems overly
broad to me.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
| |
| Russell Coker 2004-06-14, 5:53 pm |
| On Mon, 14 Jun 2004 18:46, Wouter Verhelst <wouter@grep.be> wrote:
> On Mon, Jun 14, 2004 at 05:40:05PM +1000, Russell Coker wrote:
>
> I would suggest that. SE Linux is an exception in that it needs to
> update file system attributes for /any/ installed package. Creating too
> generic solutions to such highly exceptional situations seems overly
> broad to me.
Your suggestion makes sense to me. DPKG people, what do you think? I'm ha=
ppy=20
to write the code, but I don't want to write code that will never be=20
accepted.
=2D-=20
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
| |
| Scott James Remnant 2004-06-14, 5:53 pm |
| On Mon, 2004-06-14 at 21:02 +1000, Russell Coker wrote:
> On Mon, 14 Jun 2004 18:46, Wouter Verhelst <wouter@grep.be> wrote:
>
> Your suggestion makes sense to me.
>
That would be the suggestion that has utterly failed to be elaborated,
yes?
What is "the way that rpm has been [patched]" ?
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
| |
| Russell Coker 2004-06-14, 5:53 pm |
| On Mon, 14 Jun 2004 21:10, Scott James Remnant <scott@netsplit.com> wrote:
>
> That would be the suggestion that has utterly failed to be elaborated,
> yes?
>
> What is "the way that rpm has been [patched]" ?
The /bin/rpm binary is linked against libselinux.so and has code to assign the
correct security context to each file at creation time. Doing for dpkg what
has been done for rpm means putting in SE Linux specific code for file
labelling which is not generic, and won't work for other security systems.
--
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
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Christoph Hellwig 2004-06-14, 5:53 pm |
| On Mon, Jun 14, 2004 at 09:59:21AM -0400, James Morris wrote:
>
> When did you see these figures? They are not consistent with the
> performance data I've seen.
>
> When I ran Webstone tests on x86 for the Usenix paper, there was a 5-7%
> performance hit for LSM, which dropped to 1-2% once the Netfilter hooks
> were disabled. LSM was reworked considerably before submission to the
> upstream kernel, which included dropping the Netfilter hooks, as well as
> many other hooks in the networking, and the hooking mechanism itself was
> redesigned for efficiency. LSM should have significantly less overhead
> than the 1-2% figure for web performance.
They're from a hardware vendor doing benchmarking on one of the
commercial distros. Note that this is on IA64 where gcc is particularly
bad when lots of indirect function calls are used.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| James Morris 2004-06-14, 5:53 pm |
| On Sun, 13 Jun 2004, Luke Kenneth Casson Leighton wrote:
> * debian kernels need to be available compiled with se/linux security
> enabled (and boot-time optional) by default. this results in a
> 2% performance hit (wow big deal) when se/linux is not enabled
> at boot time. Gentoo, SuSE and Fedora all accept this 2%.
Where do you get this figure from?
- James
--
James Morris
<jmorris@redhat.com>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| James Morris 2004-06-14, 5:53 pm |
| On Mon, 14 Jun 2004, Russell Coker wrote:
> On Mon, 14 Jun 2004 03:01, Christoph Hellwig <hch@lst.de> wrote:
[vbcol=seagreen]
When did you see these figures? They are not consistent with the
performance data I've seen.
When I ran Webstone tests on x86 for the Usenix paper, there was a 5-7%
performance hit for LSM, which dropped to 1-2% once the Netfilter hooks
were disabled. LSM was reworked considerably before submission to the
upstream kernel, which included dropping the Netfilter hooks, as well as
many other hooks in the networking, and the hooking mechanism itself was
redesigned for efficiency. LSM should have significantly less overhead
than the 1-2% figure for web performance.
- James
--
James Morris
<jmorris@redhat.com>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Scott James Remnant 2004-06-15, 5:55 pm |
| On Mon, 2004-06-14 at 22:34 +1000, Russell Coker wrote:
> On Mon, 14 Jun 2004 21:10, Scott James Remnant <scott@netsplit.com> wrote:
>
> The /bin/rpm binary is linked against libselinux.so and has code to assign the
> correct security context to each file at creation time. Doing for dpkg what
> has been done for rpm means putting in SE Linux specific code for file
> labelling which is not generic, and won't work for other security systems..
>
Why can't this just be done in postinst?
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
| |
| Brian May 2004-06-16, 5:56 pm |
| >>>>> "Scott" == Scott James Remnant <scott@netsplit.com> writes:
[vbcol=seagreen]
Scott> Why can't this just be done in postinst?
It has to happen for every *.deb package.
Adding and maintaining SE-Linux code in the postinst of every package
around would appear to be very impractical and unfeasible.
Such an excessive solution isn't required either, most packages don't
need any modifications to work with SE-Linux (as the policy isn't
included with the packages).
--
Brian May <bam@debian.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-06-16, 5:56 pm |
| On Wed, 16 Jun 2004 03:47, Scott James Remnant <scott@netsplit.com> wrote:
>
> Why can't this just be done in postinst?
Sure it could be done in the postinst, if I could change the postinst file of
every package in Debian and keep the changes up to date...
--
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
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Simon Richter 2004-06-17, 5:53 pm |
| Hi,
[labeling files for SE/Linux]
[vbcol=seagreen]
> Sure it could be done in the postinst, if I could change the postinst file of
> every package in Debian and keep the changes up to date...
Are these labels required for every package, or can they be left out for
programs that are meant to be called by users and need no special
privileges?
Simon
--
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4
| |
| Russell Coker 2004-06-17, 11:50 pm |
| On Fri, 18 Jun 2004 05:33, Simon Richter <sjr@debian.org> wrote:
> Hi,
>
> [labeling files for SE/Linux]
>
>
> Are these labels required for every package, or can they be left out for
> programs that are meant to be called by users and need no special
> privileges?
Most packages don't need anything special under the current policy, as in most
cases the contexts of the files match that of the directories that they are
in.
There's probably only a few hundred packages that really need per-file
labelling under the current policy.
However there can be different policies, a user could create their own policy
which requires different labelling. It is not possible for me to know the
precise list of which packages a SE Linux administrator may require such
labelling on right now, and we can expect things to change in future.
--
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
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian May 2004-06-20, 10:24 pm |
| >>>>> "Simon" == Simon Richter <sjr@debian.org> writes:
Simon> Are these labels required for every package, or can they be
Simon> left out for programs that are meant to be called by users
Simon> and need no special privileges?
They are required for every file, just like there are Unix permissions
for every file.
--
Brian May <bam@debian.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-06-20, 10:24 pm |
| On Fri, 18 Jun 2004 14:51, Brian May <bam@debian.org> wrote:
>
> Simon> Are these labels required for every package, or can they be
> Simon> left out for programs that are meant to be called by users
> Simon> and need no special privileges?
>
> They are required for every file, just like there are Unix permissions
> for every file.
Yes, but there are generalisations. Just as with Unix permissions you could
make all files in /bin, /sbin, /usr/sbin, and /usr/bin mode 0755 owned by
root:root and list the small number of exceptions we could have SE Linux type
labels be taken from the directory and make exceptions of the 500 or so
packages that would not fit with this.
Modifying 500 packages does not make sense though when we can more easily
modify a single package.
--
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
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Luke Kenneth Casson Leighton 2004-06-20, 10:24 pm |
| On Mon, Jun 14, 2004 at 09:59:21AM -0400, James Morris wrote:
> On Mon, 14 Jun 2004, Russell Coker wrote:
>
>
>
> When did you see these figures? They are not consistent with the
> performance data I've seen.
to be absolutely honest, i cannot remember.
i saw it once, in some se/linux documentation or a faq, and then
took that as read.
l.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|