Re: recommends for apparmor in newest linux-image-4.13
Le 10/12/17 à 22:21, Theodore Ts'o a écrit : On Wed, Dec 06, 2017 at 11:24:45AM +0100, Laurent Bigonville wrote: The SELinux policy could be altered to either run everything that we know is not ready to be confined in an unconfined domain or put that domain in permissive (which would result in a lot of denials being logged), so it's possible to behave more or less the same way as AppArmor depending of how the policy is designed. It "could" be altered the same way that anyone "could" modify a sendmail.cf file. Someone "could" create a program which plays the game of Go written raw assembly language. If it "could" be done, why hasn't been done in the past decade? Everything started by logged-in users is already running unconfined for years in most distributions (including debian). For the daemons (httpd,...), the goal was always to have a policy working well enough so they could be confined, but this requires work to adjust the policy to work with debian paths and software versions (these are moving targets). My idea at some point was to formalize (a subset of) use cases and test these well enough before enforcing the policy only for these. But I never had the time to formalize the use cases. Running SELinux all the domains in permissive doesn't make a lot of sense IMVHO. It's a bit of chicken-egg problem here, either we confine everything, things break and we have a high risk of people disabling SELinux or we put everything in permissive and people doesn't even see that the policy is not correct. In both case we have no bug reports, well at least that what I was afraid of and that's and why I personally never proposed SELinux to be enabled by default. Also, don't forget that the SELinux team in debian is made of 2 people, Russel for the policy and I'm taking care of the userspace. TL;DR: Not enough time/testing/manpower
Re: recommends for apparmor in newest linux-image-4.13
One thing that would be good to have is a set of profiles for Puppet or something similar for installing a variety of common Debian configurations. This could be used for testing SE Linux as well as anything else one might want to test. If we had automated tests for the most common webapps, mail server configurations, and all the other most common server packages (maybe based on popcon) it would significantly reduce the scope of problems users experience. But as noted SE Linux in Debian is me and Laurent, more help would be appreciated. Also I've seen AppArmor and Systemd both prevent reasonable configurations that aren't uncommon from working. I don't think that it's possible to provide useful security benefits without the risk of stopping operations you desire. This principle has a much wider scope than software, you can see it in all manner of physical security systems. -- Sent from my Huawei Mate 9 with K-9 Mail.
RFH: citadel/webcit
Anyone interested in citadel/webcit? If not I'm going to have it removed I guess. There used to be a team maintaining these packages, but I'm the only one who worked on it in recent years. Not having used the software myself I don't really intend to spend more time on it and both packages have an RC bug, that upstream may or may not have fixed. To explain the latter, upstream claims to have fixed it and their source is different from ours but the version number is exactly the same! Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: RFH: citadel/webcit
On 11.12.2017 13:42, Michael Meskes wrote: > Anyone interested in citadel/webcit? If not I'm going to have it removed I > guess. > > There used to be a team maintaining these packages, but I'm the only one who > worked on it in recent years. Not having used the software myself I don't > really intend to spend more time on it and both packages have an RC bug, that > upstream may or may not have fixed. > > To explain the latter, upstream claims to have fixed it and their source is > different from ours but the version number is exactly the same! You can change the b-d to libical2-dev to still build with the old libical version. afaics it doesn't link with packages now linked with libical3.
Re: recommends for apparmor in newest linux-image-4.13
On Sun, Dec 10, 2017 at 04:21:18PM -0500, Theodore Ts'o wrote: > On Wed, Dec 06, 2017 at 11:24:45AM +0100, Laurent Bigonville wrote: > > The SELinux policy could be altered to either run everything that we know is > > not ready to be confined in an unconfined domain or put that domain in > > permissive (which would result in a lot of denials being logged), so it's > > possible to behave more or less the same way as AppArmor depending of how > > the policy is designed. > > It "could" be altered the same way that anyone "could" modify a > sendmail.cf file. Someone "could" create a program which plays the > game of Go written raw assembly language. I think Laurent was wearing his "contributor to the Debian SELinux packages" hat in that that was one of the options if that's wanted, rather than the more "theoretically this is possible" thing you seem to be referring to. > If it "could" be done, why hasn't been done in the past decade? Because nobody ever thought it would be a good idea? But ideas and thoughts can change. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Has Copyright summarizing outlived its usefulness?
On Thu, Dec 07, 2017 at 05:28:12PM +, Ian Jackson wrote:
> Simon McVittie writes ("Re: Has Copyright summarizing outlived its
> usefulness?"):
> > I've written about this before, for example in
> > , and I'd be
> > very glad to see an "official" response from the ftp team.
> From what I've seen of the ftp review process, the file-by-file
> information is invaluable to ftpmaster review. As in, the ftpmaster
> review would probably be impractical without it. ftpmaster review
> necessarily focuses on the contents of the source package.
The debian/copyright isn't valuable as input to the ftpmaster review, it's
treated as the /object/ of the review and the ftp team imposes an artificial
requirement, not grounded in either Debian Policy or the requirements of our
licenses, that debian/copyright align with their analysis of the copyright
of the source package in order to clear the NEW queue.
So the ftp NEW process is auditing the wrong things, for the wrong reasons.
The purpose of debian/copyright is not to duplicate the copyright and
license information already included in the upstream sources; it's to
provide the relevant information to users who only have the binary package.
> That the information for ftpmaster review has ended up being shipped
> as the user-facing copyright notice in the binary is arguably not
> ideal for some of the reasons we have explored here.
Yes; and the way to fix this is to correct this misconception (rooted in the
historical policy error to specify copyright as a source-level file) that
debian/copyright *should* document the source copyright instead of the
binary copyright.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
ITP: golang-github-knqyf263-go-deb-version -- A golang library for parsing deb package versions
Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu
* Package name: golang-github-knqyf263-go-deb-version
Version : 0.0~git20170509.9865fe1-1
Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-deb-version
* License : Expat
Programming Lang: Go
Description : A golang library for parsing deb package versions
go-deb-version is a golang library for parsing and comparing versions.
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
ITP: golang-github-knqyf263-go-rpm-version -- A golang library for parsing rpm package versions
Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu
* Package name: golang-github-knqyf263-go-rpm-version
Version : 0.0~git20170716.74609b8-1
Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-rpm-version
* License : Expat
Programming Lang: Go
Description : A golang library for parsing rpm package versions
go-rpm-version is golang library for parsing and comparing rpm versions.
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
Re: [Pkg-citadel-devel] Bug#859789: RFH: citadel/webcit
On 2017-12-11 7:42 AM, Michael Meskes wrote: Anyone interested in citadel/webcit? If not I'm going to have it removed I guess. There used to be a team maintaining these packages, but I'm the only one who worked on it in recent years. Not having used the software myself I don't really intend to spend more time on it and both packages have an RC bug, that upstream may or may not have fixed. To explain the latter, upstream claims to have fixed it and their source is different from ours but the version number is exactly the same! We patched some of the sources in an attempt to make it work on the latest Debian, but that effort seems to have missed the mark. That having been said, we've got everything working with both old and new libical versions now, and it seems to build cleanly on both previous and current Debian versions. A new release is forthcoming so if you want to hold tight for a little while longer we should be able to smooth things out. Naturally it is up to you as package maintainer whether you want to continue to volunteer your time -- I totally respect that.
