Re: server and client in one package -> security issue

[Maxim Cournoyer]

Apologies for digging up a 2 months old message, but I felt compelled to :)

Hartmut Goebel  writes:

> Am 14.02.2017 um 10:16 schrieb Danny Milosavljevic:
>> I don't think Guix should do that, though. 
>
> I think guix should provide the tools for doing so. Guix has the big
> advantage of providing trustworthy packages, but kicks itself out of the
> race if hardening is so much complicated.
>
>> IMO locking down everything for users is basically the antithesis of the FSF.
>
> The "user" is the company, the employees work on behalf of the company.
> So the software freedom has to be available toe the company not to the
> individual employee.
>

>From what I've read and understand, freedom is for any and all
individuals running the software. The employees of your company also
deserve freedom. Freedom doesn't necessarily goes against good
security. I believe Guix and Hurd are steps in the right direction in
achieving freedom of users in a shared/corporate environment.

> As a company I'm expecting the user to *not* install software on their
> computers (not talking about developers here). Otherwise its like
> allowing workers to bring their own hammer to the building site or their
> own machines into the factory building. If the hammer is inappropriate
> and is deforming all nails, or the machine is producing scrap, the
> company the the one bear the consequences.

I believe one of GNU's goal is to bridge (remove the gap between)
developers and users. The system should empower the users to
experiment/study/learn/share the software if they want to and removing
barriers to the tools.

My 2 cents,

Maxim

Re: server and client in one package -> security issue

[Andy Wingo]

On Tue 14 Feb 2017 11:28, Hartmut Goebel  writes:

> Am 13.02.2017 um 15:13 schrieb Ludovic Courtès:
>> Now, back to the “only install the required software”, I wouldn’t go as
>> far as you do.  I generally agree with the rule, but I’m skeptical as to
>> what this buys you from a security perspective: users can always install
>> whatever they want by hand anyway, and do you have an idea as to how
>> much code they install via their browser?
>
> Looks like we are talking about different systems. I'm talking about
> hardened systems, esp. servers, where users are not allowed to install
> additional software – not even browser add-on.

If the user has no access to the Guix store and daemon, so they can't
even "guix package --install foo", then you're operating on effectively
a snapshot of the store, right?  So perhaps you want a facility that
when exporting this store snapshot can remove some subset of files, like
for example the include/ tree on all store directories.  But because
this is just an snapshot/export of the store, it doesn't seem necessary
to actually change any particular Guix package to reach your goal, as
far as I understand things anyway.

Andy

Re: server and client in one package -> security issue

[Hartmut Goebel]

Am 13.02.2017 um 15:13 schrieb Ludovic Courtès:
> Now, back to the “only install the required software”, I wouldn’t go as
> far as you do.  I generally agree with the rule, but I’m skeptical as to
> what this buys you from a security perspective: users can always install
> whatever they want by hand anyway, and do you have an idea as to how
> much code they install via their browser?

Looks like we are talking about different systems. I'm talking about
hardened systems, esp. servers, where users are not allowed to install
additional software – not even browser add-on.

Yes, even on these systems a skilled person can install any software
he/she wants. But it is much effort and requires more skills – depending
on a lot of parameters – to bring an exploit to the system as if the
exploit is already there since some software including the exploit is
already installed.

Is stress the example with the door of your flat again: For a skilled
person opening a locked door is easy even if there is a pun tumbler lock
[1]. But would you use just a ward key instead, which can be opened by
nearly anybody – and even lay the skeleton key [2] beside the door?

And this what hardening is about: reducing the attack surface and
removing as many tools as a possible.

Is a GNU/Linux distribution separates components sorrowly, its easier to
harden the system, which makes the distribution more attractive compared
to other distributions.

[1] https://en.wikipedia.org/wiki/Pin_tumbler_lock
[2] https://en.wikipedia.org/wiki/Skeleton_key

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: server and client in one package -> security issue

[Hartmut Goebel]

Am 14.02.2017 um 10:16 schrieb Danny Milosavljevic:
> I don't think Guix should do that, though. 

I think guix should provide the tools for doing so. Guix has the big
advantage of providing trustworthy packages, but kicks itself out of the
race if hardening is so much complicated.

> IMO locking down everything for users is basically the antithesis of the FSF.

The "user" is the company, the employees work on behalf of the company.
So the software freedom has to be available toe the company not to the
individual employee.

As a company I'm expecting the user to *not* install software on their
computers (not talking about developers here). Otherwise its like
allowing workers to bring their own hammer to the building site or their
own machines into the factory building. If the hammer is inappropriate
and is deforming all nails, or the machine is producing scrap, the
company the the one bear the consequences.


-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: server and client in one package -> security issue (was: Add murmur)

[ng0]

On 17-02-14 10:16:51, Danny Milosavljevic wrote:
> Hi,
> 
> I think the argument that things that don't exist can't be abused is a good 
> one.
> 
> However, a regular user can install it anyway. I don't remember when I last 
> ran "guix package -i" as root. I just run it using my regular user account.
> 
> So to separate the outputs adds just a miniscule step.
> 
> In the end, there's a trade-off to be made. Either we trust users to develop, 
> too, or not. Obviously they can use it for good or bad, then. 
> 
> I myself am a free software hacker and I'd prefer if systems automatically 
> had the development stuff installed so others can be free software hackers, 
> too.
> 
> And an experienced hacker doesn't need header files either. I made up some of 
> my own just searching Google - it's not difficult and takes about 30 min at 
> most.
> 
> If we want hardened critical production systems, I agree it should only 
> contain absolutely required files with programs as simple as one can get 
> them, use SELinux and use hardened gcc and someone should have reviewed the 
> base libraries and any other stuff that runs (basically until a reasonable 
> confidence level is reached).
> 
> I don't think Guix should do that, though. IMO locking down everything for 
> users is basically the antithesis of the FSF.
> 

Interjecting here my opinion for a short moment, I think with hardening
gcc and other parts of the toolchain more can be achieved.
I don't want to be too optimistic, but I hope to be done with one part
of this by summer (doing work in parallel).

Whatever results from this discussion should be written down in the
documentation, as this is obviously an impression and question which
could arise.

What makes my gut feeling (practical experience with hardening is
limited to the SysOps and compiling side with me) okay is that Gentoo
doesn't do much more than some Elf, PaX kernel (at your choice), GrSec
or SELinux, some tools for pax etc, and hardening the libcs.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: server and client in one package -> security issue (was: Add murmur)

[Danny Milosavljevic]

Hi,

I think the argument that things that don't exist can't be abused is a good one.

However, a regular user can install it anyway. I don't remember when I last ran 
"guix package -i" as root. I just run it using my regular user account.

So to separate the outputs adds just a miniscule step.

In the end, there's a trade-off to be made. Either we trust users to develop, 
too, or not. Obviously they can use it for good or bad, then. 

I myself am a free software hacker and I'd prefer if systems automatically had 
the development stuff installed so others can be free software hackers, too.

And an experienced hacker doesn't need header files either. I made up some of 
my own just searching Google - it's not difficult and takes about 30 min at 
most.

If we want hardened critical production systems, I agree it should only contain 
absolutely required files with programs as simple as one can get them, use 
SELinux and use hardened gcc and someone should have reviewed the base 
libraries and any other stuff that runs (basically until a reasonable 
confidence level is reached).

I don't think Guix should do that, though. IMO locking down everything for 
users is basically the antithesis of the FSF.

Re: server and client in one package -> security issue

[Ludovic Courtès]

Hello,

Hartmut Goebel  skribis:

> Am 09.02.2017 um 23:50 schrieb Ludovic Courtès:
>> I think the only reason to separate things usually is size, not
>> “aesthetics.”  So I’d be in favor of keeping both in the same output if
>> there’s no size problem.
>
> Separating clients and servers is not an "aesthetic" thing. It's a
> matter of security.
>
> One basic rule for hardening systems is: "only install the required
> software". If we munge server and clients packages, this obeys this rule.
>
> In my day-business I'm a security consultant (CISSP, CSSLP  and ISO
> 27001 Lead Implementer). And from my point of view Guix already has a
> medium problem of acceptance since it munges development-files and
> run-time files into one package - as we do for all libraries. This
> already contradicts the above mentioned basic rule.
>
> Now if Guix starts munging server and client components into one
> package, this plain disqualifies GuixSD from any security sensitive
> system. [*]
>
> [*] OTOH it opens up chances for big business: selling "Secure GuixSD"
> to customers.

Heheh, good for you!  ;-)

Seriously though, all I’m saying is that, until now, the main (only?)
criterion that we had for multiple outputs was size:

  
https://www.gnu.org/software/guix/manual/html_node/Packages-with-Multiple-Outputs.html
  https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html 
(#5)

This patch was using a different criterion.

Now, back to the “only install the required software”, I wouldn’t go as
far as you do.  I generally agree with the rule, but I’m skeptical as to
what this buys you from a security perspective: users can always install
whatever they want by hand anyway, and do you have an idea as to how
much code they install via their browser?

murmurd becomes a problem security-wise when you actually run it and
expose it to the network.  But that’s true of any piece of software that
talks to the network, especially if it’s written in C/C++.

The real solution to that is not to make it harder to install this or
that piece of software IMO.  Rather it’s to make sure they only run when
really needed, and in isolated environments as much as possible, as per
the “principle of least authority” (POLA).

WDYT?

Ludo’.

Re: server and client in one package -> security issue

[Hartmut Goebel]

Am 12.02.2017 um 13:53 schrieb David Craven:
> By development files I assume you mean header files? I don't see how those can
> pose a security problem. Can you elaborate?

Yes, I meant header files, but also pkgconfig files and all this stuff
(including documentation). Having this (and compilers, etc.) available
on the target machine makes it *much* easier for an intruder to compile
attack tools for malware on the target. If these are missing, the
intruder needs to collect a lot of information first to be able to build
tools for the target.

Of course this is not a silver bullet, but it one piece of protection.
Like a lock on the door: It may take the burglar only 2 Minutes to open
it, but less skilled ones may be discouraged. Or these 2 Minutes may
give you some advantage.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: server and client in one package -> security issue (was: Add murmur)

[David Craven]

> And from my point of view Guix already has a medium problem of acceptance
> since it munges development-files and run-time files into one package - as we
> do for all libraries.

By development files I assume you mean header files? I don't see how those can
pose a security problem. Can you elaborate?

> Now if Guix starts munging server and client components into one
> package, this plain disqualifies GuixSD from any security sensitive
> system. [*]

> [*] OTOH it opens up chances for big business: selling "Secure GuixSD"
> to customers.

I think that we provide security on a best effort basis. A high profile target
like a bank or credit card payment service will likely have their own security
team and will use guixsd as a basis for their deployment. We can not do the
work that is the responsibility of an in house sysops team.

Re: server and client in one package -> security issue (was: Add murmur)

[ng0]

On 17-02-12 13:23:09, Hartmut Goebel wrote:
> Am 09.02.2017 um 23:50 schrieb Ludovic Courtès:
> > I think the only reason to separate things usually is size, not
> > “aesthetics.”  So I’d be in favor of keeping both in the same output if
> > there’s no size problem.
> 
> Separating clients and servers is not an "aesthetic" thing. It's a
> matter of security.
> 
> One basic rule for hardening systems is: "only install the required
> software". If we munge server and clients packages, this obeys this rule.
> 
> In my day-business I'm a security consultant (CISSP, CSSLP  and ISO
> 27001 Lead Implementer). And from my point of view Guix already has a
> medium problem of acceptance since it munges development-files and
> run-time files into one package - as we do for all libraries. This
> already contradicts the above mentioned basic rule.
> 
> Now if Guix starts munging server and client components into one
> package, this plain disqualifies GuixSD from any security sensitive
> system. [*]
> 
> [*] OTOH it opens up chances for big business: selling "Secure GuixSD"
> to customers.
> 
> -- 
> Regards
> Hartmut Goebel
> 
> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
> | www.crazy-compilers.com | compilers which you thought are impossible |
> 
> 

Exactly why I think we should do this, with a more detailed reasoning.
Thanks!
-- 
ng0 -- https://www.inventati.org/patternsinthechaos/