Re: Updated SELinux Release

[Manoj Srivastava]

On Thu, 04 Nov 2004 23:06:06 -0500, Colin Walters <[EMAIL PROTECTED]> said: 

> On Thu, 2004-11-04 at 13:15 +, Luke Kenneth Casson Leighton wrote:
>> default: no.

> Why not on by default, with a targeted policy, for everyone?
> SELinux's flexibility allows one to easily turn it off for specific
> services.  There's a lot of value in preventing a compromised or
> misconfigured syslogd or portmap daemon from destroying your system.
> Not to mention Apache; with the stronger version of can_network, the
> Slapper worm would have been stopped in its tracks (no outbound port
> 80 access).  Additionally, I'm working on securing some high-risk
> software using the targeted policy; something that would be
> difficult to impossible to do without SELinux.

> The entire point of SELinux is to bring strong, flexible mandatory
> access control to a mainstream operating system (Linux).  If it's
> not enabled by default, and limited to the few of us on this mailing
> list, what's the point?  Why don't we just run say EROS
> (http://www.eros- os.org/) instead?  A: Because what makes SELinux
> interesting is that it can run all of our legacy software.  By not
> shipping it on everywhere, we're not tapping that ability.

This is all very nice, but I think we need to take an
 evolutionary change to reach that goal. The first step, far more
 palatable than forcing SELinux (even with just a targeted policy) is
 to get SELinux in the default kernels, disabled by default at boot
 time.

manoj
-- 
Harp not on that string. William Shakespeare, "Henry VI"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Updated SELinux Release

[Manoj Srivastava]

On Fri, 05 Nov 2004 00:40:41 -0500, Andres Salomon <[EMAIL PROTECTED]> said: 

> Manoj, if you're referring to our conversation earlier on IRC, I
> said that I have no personal interest in selinux, but I had no
> problems with it being included as long as it's not a significant
> performance hit.  I requested that you take it up on the
> debian-kernel list, though.  That request still stands; the kernel
> team is not a single person, nor is it comprised an IRC channel.

I've had other conversations about this. And, incidentally, if
 SELinux is compiled, but not enabled, there is _no_ perceptible hit,
 significant or otherwise.

> I assume you're referring to #249510, in which Christoph mentioned
> it was a 5% performance penalty.  That's significant, especially for
> people who don't care about selinux.  Your argument of "well it's
> not 20%, is it?" is bogus; throwing features into the kernel, each
> having a 5% performance penalty hit, quickly add up.

Before this gets out of hand, the 5-7% performance hit is for
 SELinux being enabled; merely compiling it in, and having the
 default setting being that SELinux is disabled at boot time unless
 selinux=1 is given on the kernel command line means there is _no_
 performance hit of that magnitude.

All you have is LSM, at that point, and the number  quoted
 were for SELinux enabled kernels, not justr kernels with LSM.

Now, I am not proposing we enable SELinux with a tergeted
 policy (which would incur the 5-7% hit) -- I am merely asking the
 SELinux option be compiled in for Sarge.

manoj
-- 
GOOD-NIGHT, everybody ... Now I have to go administer FIRST-AID to my
pet LEISURE SUIT!!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Alioth Project Denied

[Manoj Srivastava]

On Thu, 4 Nov 2004 18:18:43 -0600, Marcelo E Magallon <[EMAIL PROTECTED]> said: 

> On Thu, Nov 04, 2004 at 11:31:09AM -0700, [EMAIL PROTECTED] wrote:
>> Your project registration for Alioth has been denied.
>> 
>> Project Full Name: Window Maker Debian Package Project Unix Name:
>> wmaker
>> 
>> Reasons for negative decision:
>> 
>> If you decide to use an alioth project to comaintain a package, you
>> need to include a "pkg-" prefix in your project name. This is
>> required to be able to differentiate projects dedicated to Debian
>> packaging from projects where alioth is the main repository of
>> "upstream" code.
>> 
>> Please resubmit your project with a good name.

>  a) I couldn't find a policy in the website
>  b) It's very rude to reply anonymously, someone care to put a name
> behind this email?
>  c) Can't you just do it yourself?

>  But whatever, I'll jump thru the hoops if that's what it takes.

>  This project is making a custom out of threating developers like
>  crap.

Says he, trashing the alioth developers. Did you try and help
 the guys puting alioth together with their email dialogue? Did you
 even try to help improve the system instead of jumping on them and
 trashing their effort from the get-go?

Pot. Kettle. Black.

manoj
-- 
Serocki's Stricture: Marriage is always a bachelor's last option.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

mozilla-*-locale-* packages?

[Christian Perrier]

>From a thread in -devel, dated September, after an ITP for Swedish
locale files for Mozilla stuff...

Quoting Alexander Sack ([EMAIL PROTECTED]):
> Javier Fernández-Sanguino Peña wrote:
> 
> >I agree too. Actually, it makes more sense if we do a single package and
> >integrate there mechanisms to extract the needed files from xpis to
> >generate mozilla-locale-* packages instead of having each maintainer 
> >devise its own (as well as redoing the registration of the packages in 
> >mozilla as documented at [1])
> >
> >Moreover, somebody (a packaging group) could just package the locale
> >definitions available for Mozilla [2], Firefox [3] and Thunderbird [3], 
> >update them from time to time and update them whenever a new release is 
> >produced. That would avoid all the bugs related to -locale-YYY 
> >packages not allowing transitions of new Mozilla|Firefox|Thunderbird 
> >versions because they have not been updated and having the binary package 
> >proceed into testing would break them.
> >
> >I believe that's actually how Mozilla is integrated in other OS, for 
> >example, in Solaris IIRC.
> > 
> >
> I think, that this would not be too hard to implement. On the other
> hand, there would still be problems that some translations might not be
> ready if mozilla* packages become ready to go in. IMHO, doing so looks like
> a trick to declare translations not to be release critical and in fact
> inferior to normal packages.


Has there been any progress on that topic ?

The Arabeyes team (Arabic translators) want to get their ar
translations in Debian and they asked me for help.

Of course, I can post ITPs for mozilla-*-locale-ar packages and handle
such packages myself (by using another one as a model, that woulkdn't
be too hard), but it would be better integrating this in a more
general project.

Compiling in SELinux in the default kernels

[Manoj Srivastava]

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.kernel as well.

Hi,

I would once again like to bring up the possibility of
 compiling in support for SELinux in 2.6.9+  kernels, but leaving them
 disabled by default at boot time.  This can be accomplished by
 setting CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE==0 in the
 configuration  (I am attaching a suggested set of security related
 configuration options below).

The last time I brought it up, I was told that his has already
 come up on the list, and the reason we do not compile in  SELinux is
 that there is a performance hit on doing so.

On doing further research, I have discovered that yes, there
 is a 5-7% performance penalty on *running* SELinux -- but that is a
 whole different ball game. If SELinux is compiled in, and disabled at
 boot, there is no discernible performance hit -- benchamrks show that
 any effect is lost in the noise (since the only effect is that of the
 LSM hooks alone).

I think this would be really helpful to our users, since then
 they can chose to try out SELinux by just adding a stanza to grub or
 lilo -- try things out in non-enforcing mode, for instance. 

I also notice that 2.6.9 kernels are not slated for Sarge
 (having just acquired an grave bug to ensure that), I strongly urge
 that the 2.6.9 kernel configuration be modified for SELinux.

manoj

KERNEL CONFIGURATION


Under Filesystems, be sure to enable the Ext[23] extended attributes and
Ext[23] Security Labels options (CONFIG_EXT[23]_FS_XATTR,
CONFIG_EXT[23]_FS_SECURITY).  

Under Pseudo Filesystems, be sure to enable the /dev/pts
Extended Attributes and /dev/pts Security Labels options 
(CONFIG_DEVPTS_FS_XATTR, CONFIG_DEVPTS_FS_SECURITY).

Under Security, be sure to enable all of the following options:
Enable different security models (CONFIG_SECURITY)
Socket and Networking Security Hooks (CONFIG_SECURITY_NETWORK)
Capabilities Support (CONFIG_SECURITY_CAPABILITIES)
NSA SELinux Support (CONFIG_SECURITY_SELINUX)
NSA SELinux Development Support (CONFIG_SECURITY_SELINUX_DEVELOP)
NSA SELinux boot parameter (CONFIG_SECURITY_SELINUX_BOOTPARAM)


Excerpts from my working config below:
==
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
#
#
# Pseudo filesystems
#

CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y

#
# Security options
#
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
# CONFIG_SECURITY_SELINUX_MLS is not set


-- 
Trying to break out of the Tempter's control, one's mind writhes to
and fro, like a fish pulled from its watery home onto dry ground. 34
Manoj Srivastava <[EMAIL PROTECTED]>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Synching mirrors and clients (was: Re: apt-proxy v2 and rsync)

[Adrian 'Dagurashibanipal' von Bidder]

On Thursday 04 November 2004 17.46, Otto Wyss wrote:

> Why do you keep on saying this without providing _any_ figures!

Who is "you" here? Please pay attention to attribution on mailing list 
postings - especially if you're starting a new thread with your mail.  I 
posted this statement about cpu load of rsync, and did that exactly once, 
so I don't "keep saying it".  Also, I put in an IIRC, so you have clear 
indication that I'm not too sure - somebody asked about the reason, I 
answered with that I heard was the reason when the last person asked.

-- vbi

-- 
Oops


pgp5WZplFp7Wy.pgp
Description: PGP signature

Re: debian.org e-mail address and SPF/SRS

[Tollef Fog Heen]

* Matthew Palmer 

| See, that's the thing that the FAQ was unclear on.  If you don't have to
| sign all headers, then you're OK.  I was thinking the attachment of
| Received: headers as being particularly problematic.  To quote the FAQ:
| 
| "Mailing lists that do not change the content or re-arrange or append
| headers will be DomainKey compatible with no changes required. Mailing lists
| that change the message and headers should re-sign the message with their
| own private key and claim authorship of the message."
| 
| That suggests to me that sticking new headers into the mix would screw up
| the signature.

from the IETF draft:

: The current valid tags are:
[...]
:  h = A colon separated list of header field names that identify the
:  headers presented to the signing algorithm.

If this value is missing, all headers after the DomainKeys signing
header are assumed signed, which of course is not true, so you are
right that this will cause a problem with mailing lists.

I think this should be brought to the attention of the domainkeys
people, making this tag compulsory.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Compiling in SELinux in the default kernels

[Henrique de Moraes Holschuh]

On Fri, 05 Nov 2004, Manoj Srivastava wrote:
> I would once again like to bring up the possibility of
>  compiling in support for SELinux in 2.6.9+  kernels, but leaving them
>  disabled by default at boot time.  This can be accomplished by

I second this request.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


signature.asc
Description: Digital signature

Re: mozilla-*-locale-* packages?

[Aurelien Jarno]

Christian Perrier wrote:
From a thread in -devel, dated September, after an ITP for Swedish
locale files for Mozilla stuff...
I didn't pay to much attention to that thread, I am discovering it now.
Quoting Alexander Sack ([EMAIL PROTECTED]):
Javier Fernández-Sanguino Peña wrote:

I agree too. Actually, it makes more sense if we do a single package and
integrate there mechanisms to extract the needed files from xpis to
generate mozilla-locale-* packages instead of having each maintainer 
devise its own (as well as redoing the registration of the packages in 
mozilla as documented at [1])

Moreover, somebody (a packaging group) could just package the locale
definitions available for Mozilla [2], Firefox [3] and Thunderbird [3], 
update them from time to time and update them whenever a new release is 
produced. That would avoid all the bugs related to -locale-YYY 
packages not allowing transitions of new Mozilla|Firefox|Thunderbird 
versions because they have not been updated and having the binary package 
proceed into testing would break them.

I believe that's actually how Mozilla is integrated in other OS, for 
example, in Solaris IIRC.


I think, that this would not be too hard to implement. On the other
hand, there would still be problems that some translations might not be
ready if mozilla* packages become ready to go in. IMHO, doing so looks like
a trick to declare translations not to be release critical and in fact
inferior to normal packages.
IHMO, that is not very easy to do that for, at least, mozilla and 
thunderbird (but that could change in the future). The .xpi packages 
differ a lot from one language to an other, some .xpi are not available, 
you have to use a CVS (for example for the French translation of 
thunderbird).

However, for firefox that could be implemented as since version 1.0PR, 
the translations are standardized. All language teams use the mozilla 
CVS, the translations are using the same format and are available at the 
same time on ftp://ftp.mozilla.org.

--
  .''`.  Aurelien Jarno   GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net

Re: Updated SELinux Release

[Luke Kenneth Casson Leighton]

On Thu, Nov 04, 2004 at 11:06:06PM -0500, Colin Walters wrote:
> On Thu, 2004-11-04 at 13:15 +, Luke Kenneth Casson Leighton wrote:
> 
> >  default: no.
> 
> Why not on by default, 

 i would agree with stephen that it should be compiled in,
 default options "selinux=no".

 that gives people the choice, without affecting performance.

> with a targeted policy, for everyone?  

 debianites have yet to be convinced of the benefits of
 _anything_ to do with selinux [irrespective of whether they
 are actually _aware_ of its benefits]

 i specifically recall seeing a message from 2002 "the more i learn
 about selinux, i like it less and less".

 that having been said, i believe, like i think you do, that a
 targetted policy for debian _would_ make selinux much easier
 to accept.

 l.

Re: Updated SELinux Release

[Stephen Smalley]

On Thu, 2004-11-04 at 23:06, Colin Walters wrote:
> Why don't we just run say EROS (http://www.eros-
> os.org/) instead?  A: Because what makes SELinux interesting is that it
> can run all of our legacy software.  By not shipping it on everywhere,
> we're not tapping that ability.

Some of us might argue that the EROS security model is inadequate...
See DTMach/DTOS/Flask papers and reports for discussion of why
capability-based models leave something to be desired.

-- 
Stephen Smalley <[EMAIL PROTECTED]>
National Security Agency

a 'main' package from a non-free source

[Jon Dowland]

Hi All,

I was considering packaging 'Cube' (http://www.cubeengine.com/) in order
to get to grips with debian package management; and then possibly find a
sponsor.

However, there appears to be a latent licencing problem.

The engine code is distributed under a licence which I believe is free
(zlib/libpng); but various game media are licenced differently:

Game media included in the cube game (maps, textures, sounds,
models etc.) are not covered by this license, and may have individual
copyrights and distribution restrictions (see individual readmes).

So, any potential package for main would need to be split so that the
resources which weren't considered DFSG free wouldn't be packaged up
with the engine. (or the lot could probably be bundled in non-free.
Actually, I wouldn't assert that quite yet, I'd not be suprised if one
of media licences was too strict for non-free).

The trouble is, the source package has the lot of them in it. So, I'd
have to split the source package too.

Are there any other packages where the source package is not 'pristine'
but split in this fashion that I can look at?

Thanks,

-- 
Jon Dowland

Re: debian.org e-mail address and SPF/SRS

[Gustavo Franco]

On Fri, 5 Nov 2004 16:38:20 +1100, Matthew Palmer <[EMAIL PROTECTED]> wrote: 
> That's a question you'll have to ask of Yahoo and the SPF people.  My guess
> is that the pushers of these schemes want their thing adopted for whatever
> reason (corporate greed, personal gratification, whatever), but they know
> that random people don't care enough about e-mail forgery to really take it
> up.  However, most everyone online seems to be pretty pissed off about spam,
> so saying "this stops spam" will get people interested in the scheme, and
> they're hoping that people kinda forget that the system was supposed to stop
> spam when people work out, definitively, that it doesn't actually do squat
> to stop spam.
> 

"this stops spam" ? It isn't what they're saying, please read:

http://spf.pobox.com/faq.html#churn  
http://spf.pobox.com/faq.html#howworks

FYI, there are some different approaches that check different headers,
like Sender-ID but the 'publish the (spf) records' step is always
there.

Hope that helps,
Gustavo Franco -- <[EMAIL PROTECTED]>

Re: Compiling in SELinux in the default kernels

[Frederik Dannemare]

On Friday 05 November 2004 11:12, Henrique de Moraes Holschuh wrote:
> On Fri, 05 Nov 2004, Manoj Srivastava wrote:
> > I would once again like to bring up the possibility of
> >  compiling in support for SELinux in 2.6.9+  kernels, but leaving
> > them disabled by default at boot time.  This can be accomplished by
>
> I second this request.

Same here. Please include it, but at the same time I think it would be 
reasonable to wait till sarge is out, so kernel effort can be put into 
working on kernels released with sarge. Just a thought.
-- 
Frederik Dannemare | mailto:[EMAIL PROTECTED]
http://qa.debian.org/developer.php?login=Frederik+Dannemare
http://frederik.dannemare.net | http://www.linuxworlddomination.dk

Re: Compiling in SELinux in the default kernels

[Martin Pitt]

Hi!

Manoj Srivastava [2004-11-05  1:39 -0600]:
> I would once again like to bring up the possibility of
>  compiling in support for SELinux in 2.6.9+  kernels, but leaving them
>  disabled by default at boot time.
> [...]
>   I think this would be really helpful to our users, since then
>  they can chose to try out SELinux by just adding a stanza to grub or
>  lilo -- try things out in non-enforcing mode, for instance. 

I fully support this, however, SELinux seems to be a quite intrusive
story. As opposed to grsecurity/LIDS/RSBAC/etc. I think it needs a
bunch of patched system packages to work properly. 

I did not thoroughly check this recently, but I don't think that all
patches went in the default distribution already. Just look at
#227972, an outstanding RC bug with no reply, open for nearly 300 days
now. 

So in addition to providing kernel support, it would be great to also
ship the necessary user space stuff in Debian proper. Then we could
label ourselves as "SELinux support out of the box", which would be
really a good asset. :-)

Have a nice day,

Martin

-- 
Martin Pitt   http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer   http://www.debian.org


signature.asc
Description: Digital signature

Re: Updated SELinux Release

[Colin Walters]

On Fri, 2004-11-05 at 10:28 +, Luke Kenneth Casson Leighton wrote:
> On Thu, Nov 04, 2004 at 11:06:06PM -0500, Colin Walters wrote:
> > On Thu, 2004-11-04 at 13:15 +, Luke Kenneth Casson Leighton wrote:
> > 
> > >  default: no.
> > 
> > Why not on by default, 
> 
>  i would agree with stephen that it should be compiled in,
>  default options "selinux=no".

I don't believe Stephen said that.  He said that the performance hit in
that case is just the LSM hooks.

>  that gives people the choice, 

It doesn't make sense to make security a "choice".  The current Linux
security model is simply inadequate.

http://www.nsa.gov/selinux/papers/inevit-abs.cfm

> without affecting performance.

That's just a bug, and it's being worked on.  Personally I don't notice
any performance problems.

> > with a targeted policy, for everyone?  
> 
>  debianites have yet to be convinced of the benefits of
>  _anything_ to do with selinux [irrespective of whether they
>  are actually _aware_ of its benefits]

That's what we're working on.

Re: mozilla-*-locale-* packages?

[Alexander Sack]

I think, that this would not be too hard to implement. On the other
hand, there would still be problems that some translations might not be
ready if mozilla* packages become ready to go in. IMHO, doing so 
looks like
a trick to declare translations not to be release critical and in fact
inferior to normal packages.

IHMO, that is not very easy to do that for, at least, mozilla and 
thunderbird (but that could change in the future). The .xpi packages 
differ a lot from one language to an other, some .xpi are not 
available, you have to use a CVS (for example for the French 
translation of thunderbird).

Of course one would need to modify the upstream origs, but I think this 
would be ok if it resolves our problems. Nevertheless, let's wait and 
see what upstream is doing. I guess at least for thunderbird the locale 
development model will change as soon as the firefox way of handling 
locales is mature and proved to be efficient.

--
GPG messages preferred. |  .''`.  ** Debian GNU/Linux **
Alexander Sack  | : :' :  The  universal
[EMAIL PROTECTED] | `. `'  Operating System
http://www.jwsdot.com/  |   `-http://www.debian.org/

Re: Updated SELinux Release

[Luke Kenneth Casson Leighton]

On Fri, Nov 05, 2004 at 10:11:01AM -0500, Colin Walters wrote:
> On Fri, 2004-11-05 at 10:28 +, Luke Kenneth Casson Leighton wrote:
> > On Thu, Nov 04, 2004 at 11:06:06PM -0500, Colin Walters wrote:
> > > On Thu, 2004-11-04 at 13:15 +, Luke Kenneth Casson Leighton wrote:
> > > 
> > > >  default: no.
> > > 
> > > Why not on by default, 
> > 
> >  i would agree with stephen that it should be compiled in,
> >  default options "selinux=no".
> 
> I don't believe Stephen said that.  He said that the performance hit in
> that case is just the LSM hooks.
 
 oh. yes.

> >  that gives people the choice, 
> 
> It doesn't make sense to make security a "choice".  The current Linux
> security model is simply inadequate.

 response 1: *shrug*.  that's their choice - and their problem.

 response 2: you don't have to tell _me_ that - i'm the mad one who is
 actively working on a debian/selinux distro!!! :)

 response 3: _is_ it the job of debian developers to dictate the minimum
 acceptable security level?

 basically what i mean is, in gentoo, it's a no-brainer: you set options
 at the beginning of your build, come back [2 weeks? :) ] later and you
 have a system with PAX stack smashing, lovely kernel, everything
 hunky-dory.

 debian doesn't GIVE users that choice [remember the adamantix
 bun-fight, anyone?] and instead settles for about the lowest possible
 common denominator - no consideration to modern security AT ALL!

> > without affecting performance.
> 
> That's just a bug, and it's being worked on.  

 cool.

> Personally I don't notice any performance problems.
 
 maybe it's just me with my weird setup [very likely], but
 running mozilla under KDE 3.3.0 with selinux 2.6.8.1-selinux1
 on a 256mb system P4 2.4Ghz) is a 10-11 second startup,
 whereas if i set selinux=0 i've seen as fast as a THREE second
 startup time.

 i've put KDE_IS_PRELINKED=1, KDE_FORK_SLAVES=1 into the
 /usr/bin/startkde and i've run prelink, but i have the nvidia drivers
 so the x-windows glx drivers are symlinks, which stops prelink from
 being able to do its job on them.

 also i recompiled kde 3.3.0 .debs with the latest gcc 3.3.

 so i'm not _entirely_ confident that my setup is a good example to
 follow (!)

-- 
--
you don't have to BE MAD   | this space| my brother wanted to join mensa,
  to work, but   IT HELPS  |   for rent| for an ego trip - and get kicked 
 you feel better!  I AM| can pay cash  | out for a even bigger one.
--

Re: Updated SELinux Release

[Stephen Smalley]

On Fri, 2004-11-05 at 10:11, Colin Walters wrote:
> On Fri, 2004-11-05 at 10:28 +, Luke Kenneth Casson Leighton wrote:
> >  i would agree with stephen that it should be compiled in,
> >  default options "selinux=no".
> 
> I don't believe Stephen said that.  He said that the performance hit in
> that case is just the LSM hooks.

Obviously, I'd prefer the default to be selinux=1, but as a temporary
measure to getting SELinux compiled into the Debian kernel at all, I
think it is reasonable to make the boot-time default selinux=0 in their
kernel, as SuSE did with their kernel.  You can change the default via a
config option, no patch required anymore.

-- 
Stephen Smalley <[EMAIL PROTECTED]>
National Security Agency

Re: Updated SELinux Release

[Marco d'Itri]

On Nov 05, Stephen Smalley <[EMAIL PROTECTED]> wrote:

> Obviously, I'd prefer the default to be selinux=1, but as a temporary
> measure to getting SELinux compiled into the Debian kernel at all, I
> think it is reasonable to make the boot-time default selinux=0 in their
> kernel, as SuSE did with their kernel.  You can change the default via a
> config option, no patch required anymore.
Agreed. Anyway, I think that the really important part is having
userspace support, most of the SELinux early adopters are going to
compile their own kernels anyway.

-- 
ciao, |
Marco | [8983 inz3fxLlg0Dxk]


signature.asc
Description: Digital signature

Re: debian.org e-mail address and SPF/SRS

[Osamu Aoki]

Hi,

On Thu, Nov 04, 2004 at 12:22:30PM +0100, Stephane Bortzmeyer wrote:
> On Thu, Nov 04, 2004 at 12:15:19AM +0100,
>  Osamu Aoki <[EMAIL PROTECTED]> wrote 
>  a message of 47 lines which said:
> 
> > If you know easy way to avoid this problem exists, please let me
> > know.
> 
> I remail my email from debian.org machines, I do not forward it. So, I
> do not have the problem (I have others, but it is a different story).
> 
> master:~ % cat .procmailrc
> 
> :0
> ! [EMAIL PROTECTED],[EMAIL PROTECTED]

I though BSMTP is the only way and I never got around to do it [1].

This is so easy.  I should have thought about it.  Just did it.

I hope this is not heavy on our server :-)

Thanks,

Osamu

[1] http://people.debian.org/~osamu/memo.html

Re: Updated SELinux Release

[Andres Salomon]

On Fri, 05 Nov 2004 15:57:52 +, Luke Kenneth Casson Leighton wrote:
[...]
>  response 3: _is_ it the job of debian developers to dictate the minimum
>  acceptable security level?

It is the job of the kernel team to maintain the kernel.  That includes
ensuring the kernel runs correctly and quickly in the most common cases,
tailoring the kernel to the needs of our users, and allowing users to
simply drop in a kernel package and have it Just Work.  The same applies
to every other package in debian, really.  The minimum acceptable security
level falls under that, as well.  Most users are happy w/ the standard
unix permission system.  Demands for selinux are relatively new.


> 
>  basically what i mean is, in gentoo, it's a no-brainer: you set options
>  at the beginning of your build, come back [2 weeks? :) ] later and you
>  have a system with PAX stack smashing, lovely kernel, everything
>  hunky-dory.
> 
>  debian doesn't GIVE users that choice [remember the adamantix
>  bun-fight, anyone?] and instead settles for about the lowest possible
>  common denominator - no consideration to modern security AT ALL!
> 

Users always have the choice; that's what kernel-package is for.  Gentoo
requires you compile the kernel; you can do the same in debian to get
your pax/selinux/3rd party patches in your kernel.  Debian also provides
the option to simply download a kernel image, without having to bother
compiling anything.  The trade-off for doing that is that you won't get
your third party patches and unusual features.

I should probably mention that I find your claim about debian not taking
security into consideration quite insulting.  Don't expect people to bend
over backwards to accommodate your requests when you make such
inflammatory remarks.

Re: Synching mirrors and clients (was: Re: apt-proxy v2 and rsync)

[Otto Wyss]

> > > IIRC the problem is that rsync is quite CPU-heavy on the servers, so while
> > > the mirrors have the (network) resources to feed downloads to 100s of
> > > users, they don't have the (CPU) resources for a few dozen rsyncs.
> > 
> > Why do you keep on saying this without providing _any_ figures!
> 
> Who is "you" here? Please pay attention to attribution on mailing list
> postings - especially if you're starting a new thread with your mail.  I
> posted this statement about cpu load of rsync, and did that exactly once,
> so I don't "keep saying it".  Also, I put in an IIRC, so you have clear
> indication that I'm not too sure - somebody asked about the reason, I
> answered with that I heard was the reason when the last person asked.
> 
I don't meant you personally but this statement about the CPU load,
mostly accompanied with some vage numbers is repeated all the time and
whenever I ask for exact figures only excuses or even not an aswer is
provided.

Your statement about "feed downloads to 100s ...(CPU) resources for a
few dozen rsyncs" implied you have actually seen such CPU loads. Now you
say you just repeated from hear say. How much value did your message
have to the OP? Does it have any value?

Well the main problem is not your message but that nobody is able or
willing to set up a reasonable test case and provide accurate figures.
Maybe this is a non issue because Debian has more than enough systems
and don't has to care about.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/";

Re: Updated SELinux Release

[Javier Fernández-Sanguino Peña]

(...)
>  response 3: _is_ it the job of debian developers to dictate the minimum
>  acceptable security level?

yes, it is. But we have to weight in the needs of our users. We want, after 
all, our operating system to be used in a large set of environments and 
some of those might break when enabling SELinux (but we won't know until 
it's enabled so it's kind of a loophole)

>  basically what i mean is, in gentoo, it's a no-brainer: you set options
>  at the beginning of your build, come back [2 weeks? :) ] later and you
>  have a system with PAX stack smashing, lovely kernel, everything
>  hunky-dory.

In Debian is also a no-brainer, or, really, a similar no-brainer to Gentoo:

1.- Download your favorite kernel-source package
2.- Download the ExecShield/Adamatix(PaX+RSBAC)/SELinux kernel-packages
(or upstream patches)
3.- Build with make-kpkg and pointing it to the patches so that they get 
applied.
4.- Install the kernel and reboot

With sbuild/buildd etc you can actually recompile the whole distribution 
with whatever options you want to (including a patched gcc) either in your 
system or in a chroot. 

>  debian doesn't GIVE users that choice [remember the adamantix
>  bun-fight, anyone?] and instead settles for about the lowest possible
>  common denominator - no consideration to modern security AT ALL!

Debian does provide choices, the Adamantix stuff is packaged in Debian (it 
has seen few users, though). Debian does not yet provide packages compiled 
with SSP (which would be the other difference with Adamantix currently) but 
some people are working on in to find the best approach to that issue.

Maybe those choices are not sufficiently documented (or used) to be 
mainstream, but choices are there and they are as no-brainer as having a 
user compile the full Gentoo distribution.

Regards

Javier


signature.asc
Description: Digital signature

AIPS Part II

[Justin Pryzby]

Greetings,

I mailed the list recently regarding my ITP AIPS: Astronomical Image
Processing System.  For anyone who might have considered sponsoring,
here is some more info regarding its size.

Source tar.gz: 67MB
Initial .deb Size: 148MB
Current .deb Size: 16MB arch dependent, 52MB arch independent

Initially, the binary directory ($LOAD) was 200MB, which I've cut down
to 20MB by adding the ability to compile using shared libraries (not
available from the upstream compile script).  The libraries themselves
are <10MB.

This is still a huge package; it takes almost 2 hours (CPU bound) to
compile on my 850MHz laptop.  So, no, the size is not a mistake.

Still a WIP, I'm presently working on separating the compile-time from
install-time process (which are bundled in the upstream script).

Justin


signature.asc
Description: Digital signature

Re: Alioth Project Denied

[Roland Mas]

Marcelo E. Magallon, 2004-11-05 01:50:05 +0100 :

> On Thu, Nov 04, 2004 at 11:31:09AM -0700, [EMAIL PROTECTED] wrote:
>  > Your project registration for Alioth has been denied.

[...]

>  > If you decide to use an alioth project to comaintain a package,
>  > you need to include a "pkg-" prefix in your project name.

[...]

>  a) I couldn't find a policy in the website

Used to be there.  Should be restored sometime.

>  b) It's very rude to reply anonymously, someone care to put a name
> behind this email?

  This message was sent automatically by the web interface when I
(Roland Mas) denied your project.  Gforge currently does not
impersonate people, so it sends messages from a clearly invalid
address.

>  c) Can't you just do it yourself?

1. The point of Alioth (of Gforge, really) is to provide a simple and
quick way for people to register projects.  It took me about two years
to educate my co-workers about their own ability to register their own
accounts and projects instead of coming to see me with "Can you make
an account for me?" requests.  I'm surprised my esteemed fellow Debian
developers are not more clueful.

2. Yes, I could have done so.  It would however have taken time for me
to do so.  When I have that sort of time, I usually prefer working on
the next Gforge and/or the next Alioth.  Like, you know, the one where
we get rid of the infamous LDAP setup.

3. Judging by the masses of people who were confused, nay, irritated
by the fact that their loginnames were not "foo" but "foo-guest",
despite the "-guest" being prominently displayed in the "Create an
account page", if I started messing around with people's project
names, I'd probably get yelled at quite a lot.  I try to do my best to
live without being yelled at.

>  But whatever, I'll jump thru the hoops if that's what it takes.

  That would be so kind.

>  This project is making a custom out of threating developers like crap.

  Thank you.  I'll try to remember that next time I need to spend like
ten hours in a row working on fixing Alioth.  It'll give me such a
motivation.  Maybe I should even make a poster out of that.

Roland.
-- 
Roland Mas

M-x execute-extended-command

Re: Compiling in SELinux in the default kernels

[Manoj Srivastava]

On Fri, 5 Nov 2004 15:02:04 +0100, Martin Pitt <[EMAIL PROTECTED]> said: 

> Hi!  Manoj Srivastava [2004-11-05 1:39 -0600]:
>> I would once again like to bring up the possibility of compiling in
>> support for SELinux in 2.6.9+ kernels, but leaving them disabled by
>> default at boot time.  [...]  I think this would be really helpful
>> to our users, since then they can chose to try out SELinux by just
>> adding a stanza to grub or lilo -- try things out in non-enforcing
>> mode, for instance.

> I fully support this, however, SELinux seems to be a quite intrusive
> story. As opposed to grsecurity/LIDS/RSBAC/etc. I think it needs a
> bunch of patched system packages to work properly.

That is correct, and that is being worked upon.

> I did not thoroughly check this recently, but I don't think that all
> patches went in the default distribution already. Just look at
>> 227972, an outstanding RC bug with no reply, open for nearly 300
>> days now.

While it is true that selinux-policy-default is uninstallable
 in Sid, and it is not likely to be working in Sarge, the idea is to
 get the patches into core packages (coreutils, procps, etc) so that
 selinux-policy-default would actually work. Currently, there is an
 aptable repository od SELinux packages on 
deb http://www.coker.com.au/newselinux/ ./
 which is needed to get things working (and that does have the new pam
 stuff).

> So in addition to providing kernel support, it would be great to
> also ship the necessary user space stuff in Debian proper. Then we
> could label ourselves as "SELinux support out of the box", which
> would be really a good asset. :-)

I think most people are in agreement on this score.

manoj
-- 
Even a stopped clock is right twice a day. --anonymous
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Updated SELinux Release

[Colin Walters]

On Fri, 2004-11-05 at 15:57 +, Luke Kenneth Casson Leighton wrote:

>  response 3: _is_ it the job of debian developers to dictate the minimum
>  acceptable security level?

It is absolutely Debian's job to provide a baseline level of security by
default.  Debian doesn't let you install a system by default without a
root password, or install a mail server that relays mail from any IP
address, etc.  You're encouraged to create a regular user account for
logins (IIRC).  Likewise, I think it should be part of the standard
Linux security practice to have SELinux enabled by default.  With the
targeted policy and all the flexibility it offers (e.g. just turn off
protection for Apache, keep protection for named/portmap/syslog etc on),
there's very little reason not to ship it on.

Re: debian.org e-mail address and SPF/SRS

[Matthew Palmer]

On Fri, Nov 05, 2004 at 11:48:29AM -0200, Gustavo Franco wrote:
> On Fri, 5 Nov 2004 16:38:20 +1100, Matthew Palmer <[EMAIL PROTECTED]> wrote: 
> > That's a question you'll have to ask of Yahoo and the SPF people.  My guess
> > is that the pushers of these schemes want their thing adopted for whatever
> > reason (corporate greed, personal gratification, whatever), but they know
> > that random people don't care enough about e-mail forgery to really take it
> > up.  However, most everyone online seems to be pretty pissed off about spam,
> > so saying "this stops spam" will get people interested in the scheme, and
> > they're hoping that people kinda forget that the system was supposed to stop
> > spam when people work out, definitively, that it doesn't actually do squat
> > to stop spam.
> > 
> 
> "this stops spam" ? It isn't what they're saying, please read:

We've done this dance before.  I don't get as far as the FAQ, because the
misinformation starts right on the front page (http://spf.pobox.com, "What
is SPF?", third paragraph):

"SMTP receivers verify the envelope sender address against this information,
and can distinguish legitimate mail from spam before any message data is
transmitted."

That is a big leap from "can verify if a message is being sent from a
server which has been listed as being legitimate for the domain".  Burying
the real facts in the bowels of some FAQ doesn't stop the popular
misconception being "this is an anti-spam solution".

Find 10 people off the street who know what SPF is, ask them what SPF is
for, and I reckon probably at least 8 of them will say "it's for stopping
spam".  They got that impression from somewhere, and I don't see the SPF
guys madly running around trying to change that impression of their
software.  Last time this came up, someone posted an interview with one of
the SPF authors, who was quite happy to let the interviewer prattle on about
SPF being the FUSSP, without any correction.

- Matt


signature.asc
Description: Digital signature