Re: [gentoo-user] mixing predictable with old style network interface naming

2017-07-06 Thread R0b0t1
On Thu, Jul 6, 2017 at 2:44 PM, Francisco Ares  wrote:
>
>
> 2017-07-06 13:07 GMT-03:00 R0b0t1 :
>>
>> On Thu, Jul 6, 2017 at 10:51 AM, Francisco Ares  wrote:
>> > Hi, All.
>> >
>> > This is a bit odd, because of a non conventional hardware platform:
>> > Odroid
>> > (Hardkernel).
>> >
>> > But I guess overall rules apply to all.
>> >
>> > I need a second network interface, the original and single one present
>> > on
>> > the board is to be connected to a GigE camera, so I use a USB/ethernet
>> > adapter to have SSH remote access.
>> >
>> > I have set up the boot manager so that network interfaces would be named
>> > according to the predictable names rules. If not, the USB/eth adapter
>> > gets
>> > "eth0" if the device is present at boot, otherwise, it is "eth1".
>> >
>> > But if I disconnect the USB/ethernet adapter to leave the system alone,
>> > and
>> > after a while I need to take a look on what's going on and plug back the
>> > USB/ethernet adapter, it comes up as "eth0" again.
>> >
>> > Anyone could give me a hint on where to look at it?  Why the new
>> > interface
>> > is named in a way during boot and another during normal use?
>> >
>> > Thank you!
>>
>> Your question doesn't seem to involve any mixing of the naming schemes
>> at all, and it looks like the kernel you are using simply uses the old
>> style names. Can you compile your own kernel which supports the new
>> naming convention, remove net.ifnames=0 from the kernel command line
>> if it is present, or check for udev rules that perform naming that
>> overrides the default? You may wish to refer to
>>
>> https://wiki.gentoo.org/wiki/Handbook:X86/Networking/Advanced#Network_interface_naming
>> though it is not very information dense.
>>
>> Unfortunately my experience with hardkernel devices is that the
>> developers put most of their effort behind the Android release and
>> will make an Ubuntu release, if it exists, barely work. I would
>> strongly recommend not buying their devices. They barely support them
>> and without their help the devices are unsupportable.
>>
>> R0b0t1.
>>
>
>
> Thanks for the tip.  I've checked in /etc/udev files and directories, and
> there is no rule for naming interfaces.
>
> Instead of removing "net.ifnames=0" from the kernel command line, I have
> altered it to "net.ifnames=1". Gonna try removing it at once.
>

I would expect that to work as you did, are you using their kernel? If
you are I believe there is an option to force the old-style naming by
effectively removing the code which does the new-style naming. That's
why I asked.

> But, imho, Odroid is a good hardware, and I have learned a lot about Linux -
> not Android - in their Odroid magazine. And their Ubuntu image works very
> good. And, as always, there are a lot of guys in the community.
>

It is some of the best available hardware, but the support its
manufacturer provides isn't amazing. It's the bare minimum to get it
to work. Admittedly they did have a bit more customer involvement than
I've seen elsewhere at first (e.g. signing user-provided code with
Samsung keys to enable ARM TrustZone for QEMU) but they are still
focused on making money, and sell whatever it is they can as quickly
as possible and then move on to the next thing and avoid supporting
past products.

R0b0t1.



Re: [gentoo-user] mixing predictable with old style network interface naming

2017-07-06 Thread Francisco Ares
2017-07-06 13:07 GMT-03:00 R0b0t1 :

> On Thu, Jul 6, 2017 at 10:51 AM, Francisco Ares  wrote:
> > Hi, All.
> >
> > This is a bit odd, because of a non conventional hardware platform:
> Odroid
> > (Hardkernel).
> >
> > But I guess overall rules apply to all.
> >
> > I need a second network interface, the original and single one present on
> > the board is to be connected to a GigE camera, so I use a USB/ethernet
> > adapter to have SSH remote access.
> >
> > I have set up the boot manager so that network interfaces would be named
> > according to the predictable names rules. If not, the USB/eth adapter
> gets
> > "eth0" if the device is present at boot, otherwise, it is "eth1".
> >
> > But if I disconnect the USB/ethernet adapter to leave the system alone,
> and
> > after a while I need to take a look on what's going on and plug back the
> > USB/ethernet adapter, it comes up as "eth0" again.
> >
> > Anyone could give me a hint on where to look at it?  Why the new
> interface
> > is named in a way during boot and another during normal use?
> >
> > Thank you!
>
> Your question doesn't seem to involve any mixing of the naming schemes
> at all, and it looks like the kernel you are using simply uses the old
> style names. Can you compile your own kernel which supports the new
> naming convention, remove net.ifnames=0 from the kernel command line
> if it is present, or check for udev rules that perform naming that
> overrides the default? You may wish to refer to
> https://wiki.gentoo.org/wiki/Handbook:X86/Networking/
> Advanced#Network_interface_naming
> though it is not very information dense.
>
> Unfortunately my experience with hardkernel devices is that the
> developers put most of their effort behind the Android release and
> will make an Ubuntu release, if it exists, barely work. I would
> strongly recommend not buying their devices. They barely support them
> and without their help the devices are unsupportable.
>
> R0b0t1.
>
>

Thanks for the tip.  I've checked in /etc/udev files and directories, and
there is no rule for naming interfaces.

Instead of removing "net.ifnames=0" from the kernel command line, I have
altered it to "net.ifnames=1". Gonna try removing it at once.

But, imho, Odroid is a good hardware, and I have learned a lot about Linux
- not Android - in their Odroid magazine. And their Ubuntu image works very
good. And, as always, there are a lot of guys in the community.

Thank you!
Francisco


Re: [gentoo-user] mixing predictable with old style network interface naming

2017-07-06 Thread R0b0t1
On Thu, Jul 6, 2017 at 10:51 AM, Francisco Ares  wrote:
> Hi, All.
>
> This is a bit odd, because of a non conventional hardware platform: Odroid
> (Hardkernel).
>
> But I guess overall rules apply to all.
>
> I need a second network interface, the original and single one present on
> the board is to be connected to a GigE camera, so I use a USB/ethernet
> adapter to have SSH remote access.
>
> I have set up the boot manager so that network interfaces would be named
> according to the predictable names rules. If not, the USB/eth adapter gets
> "eth0" if the device is present at boot, otherwise, it is "eth1".
>
> But if I disconnect the USB/ethernet adapter to leave the system alone, and
> after a while I need to take a look on what's going on and plug back the
> USB/ethernet adapter, it comes up as "eth0" again.
>
> Anyone could give me a hint on where to look at it?  Why the new interface
> is named in a way during boot and another during normal use?
>
> Thank you!

Your question doesn't seem to involve any mixing of the naming schemes
at all, and it looks like the kernel you are using simply uses the old
style names. Can you compile your own kernel which supports the new
naming convention, remove net.ifnames=0 from the kernel command line
if it is present, or check for udev rules that perform naming that
overrides the default? You may wish to refer to
https://wiki.gentoo.org/wiki/Handbook:X86/Networking/Advanced#Network_interface_naming
though it is not very information dense.

Unfortunately my experience with hardkernel devices is that the
developers put most of their effort behind the Android release and
will make an Ubuntu release, if it exists, barely work. I would
strongly recommend not buying their devices. They barely support them
and without their help the devices are unsupportable.

R0b0t1.



[gentoo-user] mixing predictable with old style network interface naming

2017-07-06 Thread Francisco Ares
Hi, All.

This is a bit odd, because of a non conventional hardware platform: Odroid
(Hardkernel).

But I guess overall rules apply to all.

I need a second network interface, the original and single one present on
the board is to be connected to a GigE camera, so I use a USB/ethernet
adapter to have SSH remote access.

I have set up the boot manager so that network interfaces would be named
according to the predictable names rules. If not, the USB/eth adapter gets
"eth0" if the device is present at boot, otherwise, it is "eth1".

But if I disconnect the USB/ethernet adapter to leave the system alone, and
after a while I need to take a look on what's going on and plug back the
USB/ethernet adapter, it comes up as "eth0" again.

Anyone could give me a hint on where to look at it?  Why the new interface
is named in a way during boot and another during normal use?

Thank you!


Re: [gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

2017-07-06 Thread Jeriko One
On 07/06/2017 12:28 AM, R0b0t1 wrote:
> To be fair it is a bit more circuitous on Linux than it is on Windows.
> Even if you use (or abuse?) /proc as I outlined in my blurb on
> GRsecurity you can't directly cause another process to start executing
> your code directly, but you can edit its memory, debug it, and mess
> with it in almost every other imaginable way - or you can just find a
> way to get the user to execute some other executable you created on
> disk.
> 
> On Windows there exists CreateRemoteThread.[1] You can force a
> currently loaded process to run whatever code you want.

Not sure what CreateRemoteThread has to do with exploitation. You can't inject 
code in a process with higher privileges than the process you're running as.

> You can solve both of these problems with Role Based Access Controls,
> if you want to bother setting them up. Otherwise process sandboxing
> only applies to resources, not security.

Security is a problem that is never completely solved. Sandboxing and RBAC are 
good mitigations to have in place. If you were able to get code execution 
within a browser that was sandboxed, you could still interact with the kernel 
and attempt to exploit it. This is where the kernel patches that grsec provides 
really help you out. As they make successful exploitation of the kernel more 
difficult. 



Re: [gentoo-user] Re: About using only precompiled pkgs

2017-07-06 Thread Rich Freeman
On Thu, Jul 6, 2017 at 8:55 AM, Harry Putnam  wrote:
> Rich Freeman  writes:
>
> "I also have gentoo pre-build binary packages where it can
> overnight..."
>
> Not so much interested in binary... now that I see its really sort of
> a non-starter for someone looking to avoid `emerge world' where
> posssible, but I am interested in how your overnight runs are done,
> the details, as they might apply to getting parts or all of an update
> done unattended. Perhaps parts of your system can be adapted for use
> where emerging all or parts of an update are the goal.

I would tell you to search the list archives, but I really struggle to
get Google to find anything there.

At night I run a script which does an emerge --sync, emails me the
output of emerge -pu world, and then tries to build binary packages of
everything in it.

The next morning I read my email to see what is to be updated, and if
I'm happy I just do the emerge with a -k to use binary packages where
available.

I'll detail the scripts below since searching is not turning out well.

> Can you flesh out some of the details? Especially the `where it can'
> part.  How do you know what can or or can't be done unattended?

The issue is when there are layers of dependencies being built.  If
package A and B need to be updated, and B depends on A at build time,
then portage can only create a binary package for A, unless you want
it to actually install the package.  I'm not building these in some
kind of chroot or container - I'm using --buildpkgonly so it never
gets installed.

I guess another option would be to spin up a container/etc, do all the
building and packaging, and then destroy the container.  Then I'd have
a complete sent of binary packages.  I should think about that, though
I'd probably want it to use a snapshot of my root when doing so and
that could get tricky (since my host isn't intended to be used as a
template).

If you wanted to do a full unintended install there would be no issues
at all, other than the risk that you might walk in and find the
computer not working and have to figure out why.  I prefer to review
my updates before installing them - Gentoo has gotten a LOT better at
this stuff but it isn't Debian stable or RHEL/CentOS.

Here are my scripts.
This does an emerge sync (called from cron):
https://github.com/rich0/rich0-gentoo-scripts/blob/master/emergesync

This does the package builds (called from previous script):
https://github.com/rich0/rich0-gentoo-scripts/blob/master/buildupdates

This package installs the updates (called manually after I review the
emailed proposed changes):
https://github.com/rich0/rich0-gentoo-scripts/blob/master/instupdates

The whole thing could be refactored and cleaned up, since the emerge
parameters are hard-coded in each script.  But, it is good enough for
my purposes.  These are very safe to use since nothing gets installed
unless you ask for it.  It is nice having portage build chromium
overnight and then I just do a 30 second install the next morning.
However, for something like a qt/kde update you're still going to
watch a lot of stuff build.  If all it saves me is kdelibs I'll
consider it a win.

-- 
Rich



[gentoo-user] Re: CIFS mounts started misbehaving

2017-07-06 Thread Grant Edwards
On 2017-03-06, Grant Edwards  wrote:
> On 2017-03-03, Grant Edwards  wrote:
>
>> For the past 10-15 [years], I've been mounting a handfull of
>> directories that reside on a Windows server, and it's always worked
>> fine.
>>
>> About a week ago, they started acting oddly.  They all mount fine,
>> and work as usual as long as you keep using them.  AFAICT, if they
>> sit idle for "a while" (tens of minutes, maybe an hour), they
>> freeze up.
[...]
> It's a kernel 4.9 problem.
[...]
> Rebooting with the 4.4.39 kernel fixes the problem.

FWIW, I've been running 4.9.34 since yesterday, and all my CIFS mounts
seem stable.

-- 
Grant Edwards   grant.b.edwardsYow! TONY RANDALL!  Is YOUR
  at   life a PATIO of FUN??
  gmail.com




[gentoo-user] Re: About using only precompiled pkgs

2017-07-06 Thread Harry Putnam
Rich Freeman  writes:

[...] snipped informative input

> For a single system there isn't much benefit in general, though for
> reinstalls you can certainly save binary packages of everything you do
> build.  I do this for everything I build.  I also have Gentoo
> pre-build binary packages where it can overnight so that I can do
> quick installs during the day after reviewing the list of new packages
> to install.

This is something of a change of subject ... I'd be interested in
hearing more about what you are talking about when you say:

"I also have gentoo pre-build binary packages where it can
overnight..."

Not so much interested in binary... now that I see its really sort of
a non-starter for someone looking to avoid `emerge world' where
posssible, but I am interested in how your overnight runs are done,
the details, as they might apply to getting parts or all of an update
done unattended. Perhaps parts of your system can be adapted for use
where emerging all or parts of an update are the goal.

Can you flesh out some of the details? Especially the `where it can'
part.  How do you know what can or or can't be done unattended?






Re: [gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

2017-07-06 Thread R0b0t1
On Thu, Jul 6, 2017 at 1:33 AM, Martin Vaeth  wrote:
> Peter Humphrey  wrote:
>> On Tuesday 04 Jul 2017 10:14:23 Martin Vaeth wrote:
>>>
>>> With modern browsers and their complexity, you can expect that any
>>> website (or the one who has hacked it) can do anything which the
>>> user of that browser can do if he is sitting on your seat.
>>
>> Have you seen any reports of that kind of thing?
>
> Are you joking? Every CVE of the browser (or of any of its dependencies)
> which eventually allows an "execution of arbitrary code" exploit is
> such an example.
>
>> but I'd expect Linux to be less vulnerable.
>
> This has nothing to do with linux. It is the complexity of the
> browser which is the problem.
>

To be fair it is a bit more circuitous on Linux than it is on Windows.
Even if you use (or abuse?) /proc as I outlined in my blurb on
GRsecurity you can't directly cause another process to start executing
your code directly, but you can edit its memory, debug it, and mess
with it in almost every other imaginable way - or you can just find a
way to get the user to execute some other executable you created on
disk.

On Windows there exists CreateRemoteThread.[1] You can force a
currently loaded process to run whatever code you want.

You can solve both of these problems with Role Based Access Controls,
if you want to bother setting them up. Otherwise process sandboxing
only applies to resources, not security.

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682437(v=vs.85).aspx



[gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

2017-07-06 Thread Martin Vaeth
Peter Humphrey  wrote:
> On Tuesday 04 Jul 2017 10:14:23 Martin Vaeth wrote:
>>
>> With modern browsers and their complexity, you can expect that any
>> website (or the one who has hacked it) can do anything which the
>> user of that browser can do if he is sitting on your seat.
>
> Have you seen any reports of that kind of thing?

Are you joking? Every CVE of the browser (or of any of its dependencies)
which eventually allows an "execution of arbitrary code" exploit is
such an example.

> but I'd expect Linux to be less vulnerable.

This has nothing to do with linux. It is the complexity of the
browser which is the problem.