[DNG] real-world boot system modification

[Rainer Weikusat]

The powers-which-are have decreed that the process of installing our
product has to become more streamlined than "somebody booting from a
special-purpose USB device" and then enabling ssh access so that I can
do everything else interactively (not an unreasonable request as this
procedure obviously doesn't scale). Among other things, this means that
I'll no longer compile a custom kernel for each new installation in
order to support whatever Dell put into the box this time. Instead, a
more "distribution-style" kernel supporting all conceivably useful
features and every piece of not totally obsolete hardware via
modularized drivers has to be used. Even with a rather aggressive
approach wrt "considering hardware obsolete" (10/100? What's that?
Nobody uses this!), the resulting kernel + kitchen sink still ends up
needing about 160M of disk space and that's way to much for the
/-filesystems of existing installations (typically 300M). Extensive
brain surgery on these isn't really possible as burdensome people known as
'users' expect them to deliver a service to them.

Harking back to experiences with an earlier embedded OS, I came up with
the idea to turn /lib/modules/`uname -r`/kernel into a squashfs image
file and mount that over the empty directory early during the system
setup stage (/etc/rcS.d) of booting, specifically, before udev gets
started. With the sysvinit-system, this was very easily implemented by
running mksquashfs on the existing directory, creating a 2-line script
doing the mount and integrating that into the rcS-sequence by letting it
provide 'modules' and depend on mountkernfs (Required-Start) while
changing the udev Required-Start to modules (the first implementation of
this is an experiment to detemine if this can be done at all, although
this seemed very likely). Hence, 'our' main development server now runs
with a compressed kernel modules directory.

NB: This may not be the greatest idea on the planet, however, it's going
to solve my space problem with two lines of newly written code. And
that's quite ok.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Delayed E-mails

[Jaromil]

dear Jim,

On Wed, 06 Apr 2016, Jim Murphy wrote:
> 
> Did anyone else notice that at about 0726 UTC today
> the mail server, I believe, spit out 3 emails that have "been
> in hiding" for a while.  Original sent dates:

yes. they were stuck in the mailman queue until yesterday, when an
admin attended the queue using listadmin. most mails were held for
size and/or non-subscribed member.

ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another multi-user issue

[Simon Hobson]

Rainer Weikusat  wrote:

> I'd still like an answer to this question: For the common use case of a
> so-called "desktop system", why should system processes be hidden from
> its owner by default unless said owner does something which is actively
> discouraged, IOW, "Who is trying to hide what here and whose security is
> this supposed to benefit?", to word this in a somewhat loaded way.

To add my 2d worth, I can't see any reason why the single user should be hidden 
from his own system. Even when it's someone else's system (ie a work computer) 
I can't see any reason - and if it is a problem in a specific case then the 
admins can change the default.

As for the multi-user case ...
In the general case I don't see it being a problem. But a multi-user system, 
especially one where hiding processes does actually matter, will have an admin 
who should be capable of making such a decision and changing the setting.

So I've yet to see a compelling case for change.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another multi-user issue

[Rainer Weikusat]

Rainer Weikusat  writes:

> "Jack L. Frost"  writes:
>> On Sun, Apr 03, 2016 at 08:17:32PM -0400, Boruch Baum wrote:
>>> Please consider setting the default /etc/fstab to include:
>>> 
>>> proc/proc   procdefaults,hidepid=2
>>> 
>>> This has the effect of keeping the specific activities, process ids,
>>> command lines and parameters of a user from other users.
>>
>> I've been using hidepid=2 as a default in my toy distro and haven't found a
>> usecase where that would be a bad default. So unless there are common enough
>> usecases where users need to see others' processes, I agree.
>
> Since this is an argument for changing the default behaviour, there
> ought to be some "common enough" use cases where that would be
> beneficial. Eg, why should daemon processes running on a machine used by
> a single person, say, the proverbial "clueless newbie", be forcibly
> hidden from the owner of the computer unless he happens to be running as
> root?

I'd still like an answer to this question: For the common use case of a
so-called "desktop system", why should system processes be hidden from
its owner by default unless said owner does something which is actively
discouraged, IOW, "Who is trying to hide what here and whose security is
this supposed to benefit?", to word this in a somewhat loaded way.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another multi-user issue

[Rainer Weikusat]

Boruch Baum  writes:
> On 04/07/2016 01:05 PM, Rainer Weikusat wrote:
>> "Jack L. Frost"  writes:
>>> On Sun, Apr 03, 2016 at 08:17:32PM -0400, Boruch Baum wrote:
 Please consider setting the default /etc/fstab to include:
 
 proc/proc   procdefaults,hidepid=2
 
 This has the effect of keeping the specific activities, process
 ids, command lines and parameters of a user from other users.
>>> 
>>> I've been using hidepid=2 as a default in my toy distro and haven't
>>> found a usecase where that would be a bad default. So unless there
>>> are common enough usecases where users need to see others'
>>> processes, I agree.
>> 
>> Since this is an argument for changing the default behaviour, there 
>> ought to be some "common enough" use cases where that would be 
>> beneficial. Eg, why should daemon processes running on a machine used
>> by a single person, say, the proverbial "clueless newbie", be
>> forcibly hidden from the owner of the computer unless he happens to
>> be running as root?
> Nothing in Linux is done by 'force', Ranier. The sysadmin always has
> choice. The issue is whether basic security issues should be opt-in or
> opt-out.

That you keep asserting that this would be 'a basic security issue'
without ever substantiating it doesn't make it so.

> If the sysadmin of your example is so much a "clueless newbie",
> to not know how to use root (or even sudo), then no admin task
> whatsoever will be possible on the system.

In particular, when you then next suggest that any problem created by
this change can easily be solved by "well, just always run as root".

>> The 'common use case' where the default behaviour is useful would
>> still be a system with one physical user running processes supposed
>> to be various useful tasks using a variety of different user IDs. Eg,
>> the web server I'm using to get files onto iOS devices runs as
>> www-data, the DNS resolver as bind, the program getting my e-mails as
>> fetchmail, the timekeeping daemon as ntp, the line printer daemon as
>> daemon and all kernel threads runs as root. In case something "seems
>> wrong", eg, the system starts to behave sluggishly, I can do a quick
>> check of the status of everything without doing an uid change first.
>> I can check if I started the mail downloader at all with a mere ps
>> faux or pgrep fetchmail. Kernel threads using enormous amounts of CPU
>> time are visible to me without running top as root. etc
>
> Do you realize that you're basically repeating the talking points used
> by Microsoft when it originally released Windows OS?

Considering that absolutelyt nothing I wrote in the paragraph above
exists on Windows, that's a somewhat strange unsubstantiated statement.

[...]

> Linux / Unix / Solaris / etc are meant to be multi-user operating
> systems. Please remember that: multi-user.

The discussion was about "common use cases" and "single, physcial user
using a multi-user OS where different system users are used for
different purposes" is certainly a very common use case (while the
multiuser development server I mentioned earlier isn't).

> In the 1980's, Microsoft Windows decided to adopt your approach, and
> they have been back-pedaling ever since.

"In the 1980s", Microsoft was selling DOS for 16-bit computers. At the
same time, people very running seriously large time-shared UNIX(*)
installation which didn't hide the list of running processes from users.

[...]

> Likewise, Linux's design goal has never been to be a clone of your
> personal iOS devices.

I don't own any 'personal iOS devices'. I happen to have two laying
around here which are owned by my employer because I need them as client
for VPN testing. Not that this would matter anyhow.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another multi-user issue

[Boruch Baum]

On 04/07/2016 01:05 PM, Rainer Weikusat wrote:
> "Jack L. Frost"  writes:
>> On Sun, Apr 03, 2016 at 08:17:32PM -0400, Boruch Baum wrote:
>>> Please consider setting the default /etc/fstab to include:
>>> 
>>> proc/proc   procdefaults,hidepid=2
>>> 
>>> This has the effect of keeping the specific activities, process
>>> ids, command lines and parameters of a user from other users.
>> 
>> I've been using hidepid=2 as a default in my toy distro and haven't
>> found a usecase where that would be a bad default. So unless there
>> are common enough usecases where users need to see others'
>> processes, I agree.
> 
> Since this is an argument for changing the default behaviour, there 
> ought to be some "common enough" use cases where that would be 
> beneficial. Eg, why should daemon processes running on a machine used
> by a single person, say, the proverbial "clueless newbie", be
> forcibly hidden from the owner of the computer unless he happens to
> be running as root?
Nothing in Linux is done by 'force', Ranier. The sysadmin always has
choice. The issue is whether basic security issues should be opt-in or
opt-out. If the sysadmin of your example is so much a "clueless newbie",
to not know how to use root (or even sudo), then no admin task
whatsoever will be possible on the system.

> The 'common use case' where the default behaviour is useful would
> still be a system with one physical user running processes supposed
> to be various useful tasks using a variety of different user IDs. Eg,
> the web server I'm using to get files onto iOS devices runs as
> www-data, the DNS resolver as bind, the program getting my e-mails as
> fetchmail, the timekeeping daemon as ntp, the line printer daemon as
> daemon and all kernel threads runs as root. In case something "seems
> wrong", eg, the system starts to behave sluggishly, I can do a quick
> check of the status of everything without doing an uid change first.
> I can check if I started the mail downloader at all with a mere ps
> faux or pgrep fetchmail. Kernel threads using enormous amounts of CPU
> time are visible to me without running top as root. etc

Do you realize that you're basically repeating the talking points used
by Microsoft when it originally released Windows OS?

I think I'm beginning to get where you're coming from when you make your
recommendations, and that's important to know in order to respond to
you. If I do have you figured out, your issue is that you're not
thinking outside your box ("box" also in the sense of your hardware).

Linux / Unix / Solaris / etc are meant to be multi-user operating
systems. Please remember that: multi-user. In the 1980's, Microsoft
Windows decided to adopt your approach, and they have been back-pedaling
ever since. The single-user use-case is not Linux's design-goal. Those
particular Linux projects with that design goal, such as Puppy, do
address your complaint. They do so by running as root by default.

Likewise, Linux's design goal has never been to be a clone of your
personal iOS devices. Its world is a lot bigger than single-user
mobile-devices.

It might be useful to review Debian's design goal, to be "the universal
OS". Debian is meant to be used in environments that scale up past 10^4,
10^5, 10^6 + users. Their developers aren't basement hobbyists. Their
decisions are scrutinized by, and have input from, the largest of
corporations. Devuan is meant to be debian without systemd. If your
world and perspective doesn't extend past your single-user mobile
device, Debian can -also- be useful for you. It is, after all, "the
universal OS". It can be customized and tailored to your
needs. Google did so with Android; Apple based iOS on BSD. I don't
remember the others.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Building xorg-xvfb with vdev

[shraptor]

Wanting to build xorg-server-xvfb without systemd I ran into problem
with linking with vdev

make[5]: Entering directory 
'/root/Downloads/xorg-server-nosystemd/src/xorg-server-1.18.3/hw/xfree86/dixmods'

  CC   xkbVT.lo
  CC   xkbPrivate.lo
  CC   xkbKillSrv.lo
  CCLD libxorgxkb.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[5]: Leaving directory 
'/root/Downloads/xorg-server-nosystemd/src/xorg-server-1.18.3/hw/xfree86/dixmods'

  CCLD Xorg
/usr/bin/ld: cannot find -ludev
collect2: error: ld returned 1 exit status



I am running configure without --enable-config-udev


Anyone know how to get around this?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another multi-user issue

[Rainer Weikusat]

"Jack L. Frost"  writes:
> On Sun, Apr 03, 2016 at 08:17:32PM -0400, Boruch Baum wrote:
>> Please consider setting the default /etc/fstab to include:
>> 
>> proc/proc   procdefaults,hidepid=2
>> 
>> This has the effect of keeping the specific activities, process ids,
>> command lines and parameters of a user from other users.
>
> I've been using hidepid=2 as a default in my toy distro and haven't found a
> usecase where that would be a bad default. So unless there are common enough
> usecases where users need to see others' processes, I agree.

Since this is an argument for changing the default behaviour, there
ought to be some "common enough" use cases where that would be
beneficial. Eg, why should daemon processes running on a machine used by
a single person, say, the proverbial "clueless newbie", be forcibly
hidden from the owner of the computer unless he happens to be running as
root?

The 'common use case' where the default behaviour is useful would still
be a system with one physical user running processes supposed to be
various useful tasks using a variety of different user IDs. Eg, the web
server I'm using to get files onto iOS devices runs as www-data, the DNS
resolver as bind, the program getting my e-mails as fetchmail, the
timekeeping daemon as ntp, the line printer daemon as daemon and all
kernel threads runs as root. In case something "seems wrong", eg, the
system starts to behave sluggishly, I can do a quick check of the status
of everything without doing an uid change first. I can check if I
started the mail downloader at all with a mere ps faux or pgrep
fetchmail. Kernel threads using enormous amounts of CPU time are visible
to me without running top as root. etc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Enlightenment anyone? ;)

[Mitt Green]

Twisted Fate wrote:


Which version did you try?


It was with Bodhi, when it used the original E, not that
remake they use now, so probably a couple years ago.
The whole experience was pretty crappy, including "friendliness", fonts,
theme, and those shadows were very likely damned by gods.
Gimmicks, animations, transparency - all that "Linux is better than
Windows because look at this" kind of rubbish.
And this "window manager" even has a dependency on dbus.


I used e17 for a few months in early releases of
Bodhi, I had it crash few times


Ahahaha


but after a while it became really
nice. Also, system wide RAM usage for me then was amazing, around 80MB
on boot without loaded apps.


This was normal for Xfce in Debian Squeeze.

Just my two eurocents,
Mitt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] TLS / files.do

[Boruch Baum]

On 04/07/2016 07:40 AM, hellekin wrote:
> In case you didn't notice, all servers are now using proper TLS
> certificates from Let's Encrypt, except one host: files.devuan.org, that
> mysteriously failed to acquire some.  So this one is using a free
> certificate from Startcom.
> 
> If you encounter any issue with TLS, please report to
> https://git.devuan.org/devuan-infrastructure/todo/issues
> 
Didn't notice (yet). Thank you!

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] TLS / files.do

[hellekin]

In case you didn't notice, all servers are now using proper TLS
certificates from Let's Encrypt, except one host: files.devuan.org, that
mysteriously failed to acquire some.  So this one is using a free
certificate from Startcom.

If you encounter any issue with TLS, please report to
https://git.devuan.org/devuan-infrastructure/todo/issues

-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Another multi-user issue

[Trond Arild Ydersbond]

Jack L. Frost :
>On Sun, Apr 03, 2016 at 08:17:32PM -0400, Boruch Baum wrote:

>> Please consider setting the default /etc/fstab to include:
>> 
>> proc/proc   procdefaults,hidepid=2
>> 
>> This has the effect of keeping the specific activities, process ids,
>> command lines and parameters of a user from other users.

>I've been using hidepid=2 as a default in my toy distro and haven't found a
>usecase where that would be a bad default. So unless there are common enough
>usecases where users need to see others' processes, I agree.



In all cases of server use I have encountered, it has been important to see all 
processes running every now and then.  For example, running SAS on a common 
server, I regularly need to know what's going on. And with a few hundred users, 
there isn't much sense in walking around asking them.

But if you ask a manufacturer of trojans, I'm sure he will say hiding processes 
is a very important security feature. Admin  resources are often scarce, and in 
practice, much of the daily monitoring is done by ordinary users. Giving them 
su/root privileges just to watch some processes is surely not going to help 
overall security.

More generally, I think the productive way to proceed is to ask:  Which of the 
Unix defaults lead to severe problems in practice? And when such are 
identified, find out if they should change, or if the better solution is to 
issue alerts (in manpages for example) and make it easy to tighten up the 
system.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ...and when trolling went too far

[Florian Zieboll]

On Thu, 7 Apr 2016 09:38:45 +0900
Simon Walter  wrote:

> some fresh air, exercise, and a better diet


I was told that this cures excess sarcasm, too.

/sarcasm

Florian

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng