Re: Open then gates
Christoph Anton Mitterer <calestyo@scientia.net> writes:
> - Many packages contain code which does things that is questionable from
> a security point of view:
> 1) Some of them download and install data from the web (fonts, sun jdk
> doc, firmware, etc.) but do not verify them, therefore bypassing
> Debian's great secure apt system
> 2) Some do this by intention by installing plugins (firefox, josm, etc
> etc.) Of course it's probably bad to completely disable this, but the
> user is not even warned, that he gets code, which is perhaps completely
> unsecured (transmitted) and especially not covered by the security team.
These are really odd complaints to bring against Debian given that these
are not Debian issues. Firefox, for example, works exactly the same way
everywhere. What do you want Debian to do, write our own web browser?
There are limits to what a distribution can do.
>> you must not understand how user-private groups work at all
> Well I guess I do,...
Given your complaints, actually, you don't appear to.
>> and therefore think that they form some sort of security vulnerability.
> In principle yes,... but
> 1) Im not sure whether we see all possible side effects and follow-ups
> of this. There might be scripts, programs etc. which do not correctly
> set their own (secure) unit mask and thus create files which are to
> open. This may even apply to system services. Even in upcoming
> versions.
For example, here, you don't appear to understand that we're talking about
the user umask, which should not be affecting system services, and that
with the existence of user-private groups, creating files with mode 664
(outside of setgid directories) is exactly as locked down as creating
files with mode 644 without user-private groups. That's the whole point
of having them.
> 2) Users may add other user to their own group, thinking that they've
> removed group write permissions on all files, where they do not want to
> allow this. But new files may be created later where this could be
> security critical.
If regular users can add other people to groups on your system, you have
way more serious security problems than user-private groups, and those
security problems are not created by Debian.
> 3) I'd generally say, no other user should be every trusted. Never!
> E.g. You wouldn't (usually) create firewall rules that blacklist ports
> but such rules which whitelists them. The same should apply here, even a
> trusted user (which was added to the UPG) should generally not be
> trusted but only selectively for certain files.
And here, you appear to have completely misunderstood the purpose of
user-private groups in exactly the way that I tried to explain earlier.
If there is anyone in a user-private group other than the user
corresponding to it, you have broken user-private groups and created a
security hole on your system. But that's your misconfiguration, not
something Debian did.
So it seems like indeed I was right: you're upset because you don't
understand user-private groups and don't know how they work.
> Personally I'd even say we should choose a default umask of 077.
There are a lot of arguments for that, and a lot of arguments against it.
That's well-established to be something that people are not going to agree
on, and every distribution picks something and leaves that to site policy,
rightfully. 022 is the "standard" default choice, and I think it's more
appropriate for a free software distribution, although I know that by
itself is a moderately controversial statement.
I'm paranoid by profession, and I'm still in the 022 camp, so I don't
think this is a clear-cut decision.
A umask of 002 with UPG is almost completely equivalent to a umask of 022
without UPG.
>> My personal experience with portmap is that, for most systems, I don't
>> want it installed at all, and for those systems where I need it
>> installed, I also need it to respond to public network interfaces
>> because it's there in order to provide rendezvous service for network
>> services.
> You need for example for fam, where it's fully enough to have it bound
> to loopback.
gamin is a superior implementation of the idea of fam for several reasons,
one of them being that it doesn't require portmap at all. If you're
concerned with security, I encourage you to uninstall fam and install
gamin and then stop worrying about this.
> You need it for nfs-common... now you say one probably want's to have it
> then listening to all interfaces,... but I can imagine that people
> install it just because nfs is such a common thing and they want to have
> the manpages in place.
That seems like a rather questionable thing to do and then complain about
the security stance of the distribution.
>> I appreciate Debian's committment to allowing portmap to not be
>> installed at all so that I can purge it completely on most systems. A
>> package that isn't even installed is better than a package that's
>> installed and listening to localhost.
> Of course,...
> But maybe on needs NFS, and needs it just a several places, or very
> rarely. Such people want to have the packages installed, but perhaps
> disable it (portmap) per default and just enable it, when they really
> need it?
If you're sophisticated enough to do that, you're sophisticated enough to
configure it to listen only to localhost. It's not like it's hard.
> Mostly,... but sometimes (!), maintainers to not react at all or simply
> say a change is not needed (I've tried for example to convince some of
> them to not use MD5 but something better, without success).
You do realize that MD5 is still secure against preimage attacks and
replacing MD5 in an existing protocol (as opposed to when designing a new
protocol) is only warranted if you're anticipating a collision attack or
if it's a fairly trivial amount of work, right?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: