FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-07-2008, 04:38 AM
Manoj Srivastava
 
Default Changing priority of selinux back to optional

On Tue, 5 Feb 2008 23:19:14 +0100, Frans Pop <elendil@planet.nl> said:

> The priority of selinux packages was changed from optional to
> standard, fairly shortly before the release of Etch.

> I propose to revert that change before Lenny. The basic reason is that
> the selinux packages have basically been unmaintained since the
> release of Etch. Because of that current SeLinux just cannot be
> expected to work.

While this is mostly true (I have been swamped in real life
work), I do expect tha to change this spring (indeed, most of the
SELinux packages are now sitting in incoming -- happy happenstance)

> An additional reason is that the installation of selinux packages adds
> significantly to the size of the base system and accounts for a
> significant part of the time it takes to install the "standard" task,
> especially on slower architectures. This would be OK if there were
> real benefits in having SeLinux, but ATM that benefit is just not
> there.

I am not sure I agree. SELinux is working for me in production
on Lenny/Sid machines;

> Packages (both tools and policy packages) currently available in
> unstable and testing are seriously outdated when compared with their
> upstream versions. This also means that, with the soft freeze for
> Lenny starting fairly soon, that there is little time left to
> substantially improve the SeLinux support in Debian, which was one of
> the arguments for making it standard in the first place.

Err, I think you are making far too much of the amount of effort
required. While we are a few minor version behind; updating it was a
days effort -- apart from policy, which I'll get to tomorrow.

So I am not sure we are in dire straits, but y'all will have to
make that decision.

> Some facts.

> Package etch lenny/sid upstream policycoreutils 1.32-3 2.0.16-1 2.0.42
> (?) setools 2.4-3 2.4-3 3.3.2 refpolicy 0.0.20070507-5 0.0.20070507-5
> 20071214 libsepol 1.14-2 2.0.3-1 2.0.20 (?) libselinux 1.32-3
> 2.0.15-2 2.0.50 (?)

> None of the packages in Debian has been updated since June/July 2006.

That is indeed true. It is also nmo longer the case, but I
can't excuse the fact that I have been very busy.

> There are also some longstanding bugs, including fairly simple
> packaging errors in Etch, none of which have been addressed. Examples:
> - #440474: chcat: syntax errors
> - #405975: semodule_deps and semodule have alignment issues
> - #427906: postinst: policy package name to deb name, lacks glob
> #support
> - #438604: selinux-basics: Invalid test for dynamic motd updating
> - #438706: selinux-doc: Error in doc-base definition
> - #438887: refpolicy: Spurious "+" causes warnings when building
> #modules

> None of these bugs has seen any reaction from the package maintainers.

Mostly fixed.

manoj
--
Excess of grief for the deceased is madness; for it is an injury to the
living, and the dead know it not. -- Xenophon
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-07-2008, 04:43 AM
Manoj Srivastava
 
Default Changing priority of selinux back to optional

On Wed, 06 Feb 2008 00:49:01 +0100, Erich Schubert <erich@debian.org> said:

> Hello Frans, Hello fellow DDs, Yes, the SELinux stuff doesn't seem to
> have any currently active developers. I haven't heard anything from
> Manoj in months.

I haven't been around a whole lot, no.

> Anyway, back to the original topic:
> 1. I agree that SELinux currently is not in shape for a release. The

I don't think Lenny is in shape for a release either. It took
me about a day to get most SELinux packages back up to date -- which
means we could have them updated anytmime in the last few months, if
any one had the time or motivsation.

I ought to be back, now that we have survived the end of the
year dog and pony show at work.

> packages are seriously outdated, there have been some major changes in
> upstream. In particular, the 'targeted' and 'strict' policies have
> been merged and only differ by having a 'targeted' module
> installed. AFAIK.

That is the case in the policy we have currently in Sid as well.



> 2. At least libselinux is linked by many of the core packages, and the
> package REALLY should be updated nevertheless. However that might
> require also updating most of the other packages; I'm not sure about
> API compability.

You update most libraries in sync, and most of the utility
packages. Done today.

> 3. In my experience, none of the SELinux librarys or applications were
> particularly hard to package/maintain. All the hard work is in
> fine-tuning the policy to support all the Debian-specific stuff.
> Especially when you need the cooperation of other maintainers, such as
> initscripts: http://bugs.debian.org/390067 cron:
> http://bugs.debian.org/333837 liblzo1:
> http://bugs.debian.org/336138All of which have been open in the
> range of 1.5-2.5 years.


Well. Currently, I think the new setools, polgen, and slat
packages _are_ hard. The refpolicy is not easy either, and not because
of packaging, but because of the testing that needs to be done with any
change.

> So maybe it would be better to actually get some people involved in
> SELinux again.

That would indeed be nice.


manoj
--
"Intelligence without character is a dangerous thing." Steinem
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-07-2008, 04:48 AM
Manoj Srivastava
 
Default Changing priority of selinux back to optional

On Wed, 6 Feb 2008 12:27:45 +0100, maximilian attems <max@stro.at> said:

> so asking if the SELinux team is ok with adding me as co-maintainer?
> thanks Erich for your concise posting on where the work needs to be
> picked up!

The place we need most work is
1) slat
2) polgen-dfsg (I need to redo python packaging in there)
3) setools (I am packaging 3.3.2, and that seems to need a whole slew
of new packages, new libs -- libqpol, libpoldiff, etc, and new
python and java binding packages)
4) policy. Wait until the new policy upload tomorrow, and then see
how to deal with any errors that arise on your machine. This is
where the most help is needed.

If people send in patches, I'll try to maintain a less than
seven day turn around time on them starting this weekend.

manoj
--
Is there another word for synonym? George Carlin
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-07-2008, 05:02 AM
Christian Perrier
 
Default Changing priority of selinux back to optional

Quoting maximilian attems (max@stro.at):

>
> but currently willing to work on i'd nack fjp requests.
> of course if no progress has been made in a month,
> his request is more then reasonable.


I slightly disagree. Not that I have doubts about your commitment, but
this entire discussion showed that SELinux is, right now, not ready
for being included in default installs. As D-I is preparing a beta
release, it could be better to downgrade selinux stuff to optional
before that release.

It can still be reactivated later in case the progress you bring
proves to be enough for this.

Possible alternative: create a tasksel's task to include it, which
would make testing of installs with SELinux by default easier. Being
something not really end user-oriented, that would have to be a
"hidden" task (not shown as a choice by tasksel) that one could choose
with the appropriate D-I boot option.
 
Old 02-07-2008, 06:42 AM
Andreas Tille
 
Default Changing priority of selinux back to optional

On Thu, 7 Feb 2008, Christian Perrier wrote:


Possible alternative: create a tasksel's task to include it, which
would make testing of installs with SELinux by default easier.


I would be in great favour of this.


Being
something not really end user-oriented, that would have to be a
"hidden" task (not shown as a choice by tasksel) that one could choose
with the appropriate D-I boot option.


Hmmm, why hidden? In how far are other tasks more or less user-oriented?

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-07-2008, 07:01 AM
Manoj Srivastava
 
Default Changing priority of selinux back to optional

On Thu, 7 Feb 2008 07:02:40 +0100, Christian Perrier <bubulle@debian.org> said:

> I slightly disagree. Not that I have doubts about your commitment, but
> this entire discussion showed that SELinux is, right now, not ready
> for being included in default installs. As D-I is preparing a beta
> release, it could be better to downgrade selinux stuff to optional
> before that release.

Could we have some concrete guidelines about what needs to be in
place before SELinux could be considered "ready" ?


> It can still be reactivated later in case the progress you bring
> proves to be enough for this.

> Possible alternative: create a tasksel's task to include it, which
> would make testing of installs with SELinux by default easier. Being
> something not really end user-oriented, that would have to be a
> "hidden" task (not shown as a choice by tasksel) that one could choose
> with the appropriate D-I boot option.

Secondly, what are we considering removing from standard? I
would be OK with removing the targeted policy from standard; which
seems to be the largest package out there which is in standard.

libselinux1 (165KB installed) and libsepol1 (320KB installed)
seem to be the only required packages; the rest are things we can
discuss.

Additionally, in recent libselinux releases, work has been put
in to slim down the library, and reduce the burden on low space
installations.

manoj
--
"Freedom is just Chaos, with better lighting."-Alan Dean Foster "To the
Vanishing Point"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-07-2008, 08:10 AM
Václav Ovsík
 
Default Changing priority of selinux back to optional

On Wed, Feb 06, 2008 at 11:43:54PM -0600, Manoj Srivastava wrote:
> I don't think Lenny is in shape for a release either. It took
> me about a day to get most SELinux packages back up to date -- which
> means we could have them updated anytmime in the last few months, if
> any one had the time or motivsation.

Yes, updating packages is not so much work. Some work is done already be
me. Packages are compiled in binary form only for Etch at repository
http://linux.i.cz/debian/ selinux-etch. I hope sources are usable for
Sid http://linux.i.cz/debian/dists/selinux-etch/main/source/Sources.gz.
Repository is managed by reprepro and packages lays in to pool. I can
rebuild packages for Sid and create repository selinux-sid if anyone
there wants. (In that case I must probably rebuild Etch variants with
some different release number to prevent collision between Etch & Sid
variant. I think, that after some cleanup (changelog), you can use some
packages from this repo. All packaging (except clear backports
Sid->Etch) is versioned using git-buildpackage (currently not
accessible). Code is taken from subversion
https://selinux.svn.sourceforge.net/svnroot/selinux/trunk

Repository contains:

icz-archive-keyring 2007.07.31
- repo key

pam 0.99.9.0-0.icz.1
- Sid contains 0.99.7.1, with 0.99.9.0 works
initialization of user context.
Upgrade or patch in Sid is needed.

checkpolicy 2.0.9.svn20080204.r2784-0.icz.1
libselinux 2.0.51.svn20080205.r2790-0.icz.1
libsemanage 2.0.23.svn20080206.r2791-0.icz.1
libsepol 2.0.20.svn20080204.r2778-0.icz.1
policycoreutils 2.0.42.svn20080202.r2776-0.icz.1
sepolgen 1.0.11.svn20080123.r2738-0.icz.1
- staff from selinux.svn.sourceforge.net.
There are changes into Manojs packaging, because newer python bindings
needs version python2.5, wich is unsupported in Etch.

setools 3.3.2-0.icz.3
- This packaging is also changed, because of new libs (libqpol,
libpoldiff...)

shadow 1:4.1.0-2~icz40+1
tk8.4 8.4.16-1~icz40+1
ustr 1.0.3-1~icz40+1
- these are only backports from Sid


I used CDBS for packaging (where packaging changed), because it is easy
& pretty.

Openssh package of Sid needs change, because it has problems with
initialization of user context. (Not the case for Etch openssh.)

Package policycoreutils contains a patch for fixfiles, witch is
currently broken in the svn repo yet (but reported). Fixfiles is called
from selinux-basics for relabeling.

I hope something from this can be useful for Debian, at least this is
interesting exercise for me .

And yes the refpolicy is the most hard work! I simply builds policy from
sources. There is too much problems to package it yet I think.
Version of generated policy should be decreased according to kernel
version (/selinux/policyvers) in /etc/selinux/semanage.conf.

> I ought to be back, now that we have survived the end of the
> year dog and pony show at work.
>...

Nice to read this. Thanks.

Cheers
--
Zito


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-07-2008, 09:34 AM
Manoj Srivastava
 
Default Changing priority of selinux back to optional

On Thu, 7 Feb 2008 10:10:19 +0100, Václav Ovsík <vaclav.ovsik@i.cz> said:

> On Wed, Feb 06, 2008 at 11:43:54PM -0600, Manoj Srivastava wrote:
>> I don't think Lenny is in shape for a release either. It took me
>> about a day to get most SELinux packages back up to date -- which
>> means we could have them updated anytmime in the last few months, if
>> any one had the time or motivsation.

> Yes, updating packages is not so much work. Some work is done already
> be me. Packages are compiled in binary form only for Etch at
> repository http://linux.i.cz/debian/ selinux-etch.

Thanks for your work for getting backports into Etch.

> I hope sources are usable for Sid
> http://linux.i.cz/debian/dists/selinux-etch/main/source/Sources.gz.Repository
> is managed by reprepro and packages lays in to pool. I can rebuild
> packages for Sid and create repository selinux-sid if anyone there
> wants. (In that case I must probably rebuild Etch variants with some
> different release number to prevent collision between Etch & Sid
> variant. I think, that after some cleanup (changelog), you can use
> some packages from this repo. All packaging (except clear backports
> Sid-> Etch) is versioned using git-buildpackage (currently not
> accessible). Code is taken from subversion
> https://selinux.svn.sourceforge.net/svnroot/selinux/trunk

Well, don't bother with the SELinux packages; most of them are
already in Incoming, though I am not packaging straight out of SVN yet.
I'm sticking to the released versions, until I can see a clear need to
go to SVN HEAD ...

> checkpolicy 2.0.9.svn20080204.r2784-0.icz.1 libselinux
> 2.0.51.svn20080205.r2790-0.icz.1 libsemanage
> 2.0.23.svn20080206.r2791-0.icz.1 libsepol
> 2.0.20.svn20080204.r2778-0.icz.1 policycoreutils
> 2.0.42.svn20080202.r2776-0.icz.1 sepolgen
> 1.0.11.svn20080123.r2738-0.icz.1
> - staff from selinux.svn.sourceforge.net. There are changes into
> Manojs packaging, because newer python bindings needs version
> python2.5, wich is unsupported in Etch.

Hmm. My packaging does not care, really, what the python
versions available are; and so on my machine at the moment it provides
both 2.4 and 2.5 bindings (using python-support). What changes did you
think needed to be made in the packaging?

> setools 3.3.2-0.icz.3
> - This packaging is also changed, because of new libs (libqpol,
> libpoldiff...)

Yes, I am still pondering how many packages I need to split this
into. There are 5 shared libraries, with different so names and
releases (so could be 2 packages per library -- 10 packages), then
there are python bindings (can be just one package), there are java
bindings (another package), and then there are the tools tehmselves,
adding up to 13 packages.

> I used CDBS for packaging (where packaging changed), because it is
> easy & pretty.

Well, that makes the packaging effort a non-starter for me; I
don't want to have to switch into CDBS.

> Openssh package of Sid needs change, because it has problems with
> initialization of user context. (Not the case for Etch openssh.)

Could you expand on this, please?

manoj

--
Americans are people who insist on living in the present, tense.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-07-2008, 10:47 AM
Václav Ovsík
 
Default Changing priority of selinux back to optional

On Thu, Feb 07, 2008 at 04:34:58AM -0600, Manoj Srivastava wrote:
>..
> Well, don't bother with the SELinux packages; most of them are
> already in Incoming, though I am not packaging straight out of SVN yet.
> I'm sticking to the released versions, until I can see a clear need to
> go to SVN HEAD ...

I had problems with home dir contexts (generating user contexts for
actual mapping system user to SELinux user) with this versions. Must to
say, I didn't to attempt to analyze the problem to much. I went for
newer versions (and some dependency problems too), because I saw, that
Fedora uses these.

E.g. F8 uses:
checkpolicy-2.0.4
libselinux-2.0.43
libsemanage-2.0.12
libsepol-2.0.15
policycoreutils-2.0.33

and maybe these packages are patched a lot.

>...
> Hmm. My packaging does not care, really, what the python
> versions available are; and so on my machine at the moment it provides
> both 2.4 and 2.5 bindings (using python-support). What changes did you
> think needed to be made in the packaging?

This is probably no problem on Sid. Your packaging is ok there.

zito@sid:~$ pyversions -s
python2.4 python2.5

zito@etch:~$ pyversions -s
python2.4

Etch has python2.5, but it is not supported. I must change your
packaging a bit, so this version (python2.5) was used on Etch for
bindings python-semanage.

> Yes, I am still pondering how many packages I need to split this
> into. There are 5 shared libraries, with different so names and
> releases (so could be 2 packages per library -- 10 packages), then
> there are python bindings (can be just one package), there are java
> bindings (another package), and then there are the tools tehmselves,
> adding up to 13 packages.

I did that packages only, so seaudit can run. There is a gap probably.
I did only binaries:
setools
libsefs4
libsefs-dev
libseaudit4
libseaudit-dev
libapol4
libapol-dev
libqpol1
libqpol-dev
libpoldiff1
libpoldiff-dev
libsetools-tcl
You can see at http://linux.i.cz/debian/pool/main/s/setools/

> Well, that makes the packaging effort a non-starter for me; I
> don't want to have to switch into CDBS.

I thought this when I see your worked up system .
CDBS can reduce packaging code duplication, I think.

> > Openssh package of Sid needs change, because it has problems with
> > initialization of user context. (Not the case for Etch openssh.)
>
> Could you expand on this, please?

http://readlist.com/lists/tycho.nsa.gov/selinux/1/9751.html

Cheers
--
Zito


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-07-2008, 11:34 AM
Stefano Zacchiroli
 
Default Changing priority of selinux back to optional

On Wed, Feb 06, 2008 at 06:49:20PM +0100, maximilian attems wrote:
> but currently willing to work on i'd nack fjp requests.
> of course if no progress has been made in a month,
> his request is more then reasonable.

I disagree that simply willingness can nack Frans' request.
If the current situation is "bad", and I assume that trusting Frans'
words, and it has been like that for long, then the request should be
fulfilled now. Later on, if your willingness to work turns out in good
result it can be reverted.

This of course has nothing to do with mistrusting your commitment, it's
simply good management of open source project: every times people say
"I'll do that, I'll do that other", and several times the words are not
followed by facts. To be on the safe side one has to trust only facts.

Cheers.

--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/
(15:56:48) Zack: e la demo dema ? / All one has to do is hit the
(15:57:15) Bac: no, la demo scema / right keys at the right time
 

Thread Tools




All times are GMT. The time now is 04:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org