Re: [Dng] Another reason of why I am considering Devuan
> > I used to work for multiple ISPs, and I can tell you a few things for what > little they are worth. The source and destination IPs are tagged on each > packet sent over Internet. If you are tracking someone from a browser, which > is a higher level protocol than DNS, you have no need to correlate DNS calls. > Worrying about providers logging DNS traffic is a fairly pointless time > waster. > Are you sure this line of reasoning is consistent: - Martin was justifiably upset that if he sets *no* nameserver, the code defaults to google, and that this behaviour won't be changed - First of all: no name server should mean *no* nameserver (cause maybe he only wants to serve names out of /etc/hosts only or something). Remember: No means no - the software should obey its users not the other way around - You said google wasn't a problem cause the ISP might log DNS as well, so one might as well go with google - Now you appear to say that the ISP could log/see anything at a different level anyway. This implies that if we were to use google DNS, *both* google *and* the ISP have the data, while if one were to go with the ISP DNS, then *only* the ISP would have it, which we can agree is a better situation (the latter being a proper subset of the former). Particularly as there are many ISPs - so the data isn't as concentrated, and some ISPs actually operate in jurisdictions with some privacy protections - On top of that you don't think google is that bad cause you say: "Even so, if Google is monetizing DNS data, Adam, in what way does that violate anyone's privacy? DNS calls are nonspecific data, associated only with your carrier's dynamic IP address, not a specific user." So DNS queries can be lined with HTTP requests, and if you pay attention to the number of sites with googleanalytics or googleapis in them, it is trivial for google work out the full set of DNS requests on a per person basis too. You said you worked for multiple ISPs - surely this would be obvious then ? Now recall that google was bust in France for collecting not only street-view pictures but also sniffing wireless access points. And now with all the andriod phones in the wild, we have google trying to know the password, mac addresses and building photo for most access points on the planet - are you really sure we should trust them with even more data ? Could it be we have some sort of Stockholm Syndrome where people whose data is captured at google start emphasising with the captor ? Or maybe we dimly remember that somewhere they use Linux and claimed that they weren't doing evil, so that is all ok, lalala ? Maybe we aren't immune to marketing after all, and careful lines of reasoning get clobbered by those with adwords ? regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status updates
> On 30/04/2015 22:35, Joerg Reisenweber wrote: > >exactly this PATH issue is what I expect and appreciate here: I do NOT > >expect > >command autocompletion of normal user to get confused by command names that > >are not supposed to even be in user's PATH > > 0700 for root-only binaries would hide them from your shell's > autocompletion. Which would be lots of stat() system calls. Which is probably fine on a horribly overspecced PC, but not so great on a phone or watch or smart-dust or whatever the next big thing is going to be. Also on paranoid systems /sbin and /usr/sbin can itself be made 0700 or 0750, so that random users can't even work out what admin commands might be there (hide suid exploits) Or /sbin can be deleted/omitted entirely on containers/virtual images where all admin has been done already. So there are very good reasons for keeping the classic/standard layout. I am going continue following up this in another one of your emails - a number of assertions you make should not go unchallenged regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] FS structure: Was vdev status updates
Me again
So I am going to quote Laurent a bit out of order, sorry about
that, but it seems the best way to explain things:
> >Now as for other assertions in this thread that the FHS itself is
> >obsolete and violations of it should not be considered a bad thing, just
> >no.
>
> I don't think anyone said that.
And then in another mail the same Laurent says:
> Some of the original design decisions for the Unix directory structure,
> that you still find in the FHS today, never made sense. Most of them made
> sense at the time, but are obsoleted by today's needs. And some of them
> still make sense today.
... confusing - it is unclear if he is arguing that departures from the
standard should be entertained or not.
My argument is that the FHS should be followed, particularly for
devuan - the way I see it the motivation to work on devuan is that
debian has lost the plot and is making large-scale and ill-conceived
changes, and there are enough people who are keen on a classical unix
init/desktop/filesystem to fork to retain this.
Over to Laurent again:
> >The FHS was carefully designed
>
> Stopped reading there.
I think that is the problem right there.
Maybe design is the incorrect phrase, maybe say "carefully evolved".
There is a view that large complex systems do not get designed
in one go, they get built incrementally - and that the collective
experiences of many years of use are encoded in it.
Specific to the unix world, I think it was Henry Spencer who
said "Those who do not understand unix are doomed to re-invent
it[, poorly]".
And lets see this in action: The original unix approach was to
have a small/fast filesystem with just the essentials on it to
get the system going, so that the rest could be gotten somewhere
else, maybe /usr (ro) of the network and say /home (rw) from
some other server.
And now we have the inexperienced but loud-mouthed crowd show up and
tell us that the world has changed, that this isn't needed, disks
are all large and fast, nobody uses NFS and get with the times,
and /bin and /usr/bin get mushed together. All very modern.
Except we now have an initramfs which, big surprise, is a small fast
filesystem there to get the system going, so that the rest of
of the system can be gotten via, say raid/lvm over iSCSI - over
the network. The more things change the more they stay the same...
Except initrds are a poor imitation: Their layout varies wildly between
distributions, they are usually hidden from view, they can easily
become out of sync, they duplicate binaries and modules unnecessarily,
require a brittle pivot_root operation (amongst other deficiencies).
Yes I know *why* they exist - the bootloader loads them rather than
the kernel. I am not saying that there is absolutely no use for them...
But in a sane world there would be and option to have initrd
and {/{bin,lib,sbin} be the same - there would be no pivot_root.
It would require some care - /etc (and maybe /dev) would have to be
their own fileystems, and there would be a command called sync-initrd
which would take the root filesystem and build the initrd image to save
in /boot - essential kernel modules would live in /lib, the rest
would be symlinks into /usr/lib/modules, or modprobe would
use PATH concepts. And everybody would understand exactly why /bin
and /usr/bin are separate entities, and the cost of bloating up /sbin
or /bin would be obvious in increased bootup times and memory use.
Maybe devuan, once it it has solved all the other debian problems can
tackle this :)
More generally: The way I understand it, devuan is a reaction to
radical changes in debian and most other linux distributions - if
we take the classical/conservative/reactionary/careful tack, then
sticking to the FHS is consistent with that approach. People who want
to try new!exiting!web2.0! stuff have no shortage of other
distributions to try. Pity for them is that just when they have
gotten used to it, there will be more new!exiting! stuff, cause
last years filesystem hierarchy is obsolete too - upgrade treadmill
for the win.
regards
marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status updates
Hello again > >> 0700 for root-only binaries would hide them from your shell's > >> autocompletion. > > > >Which would be lots of stat() system calls. > > If a shell doesn't make them, then it doesn't verify that a file is > executable either. (I just checked with zsh: it doesn't indeed.) > Sure, few people will install non-executable files in PATH search > locations, but if autocompletion doesn't guarantee that a filename > it prints will be executable, then it shouldn't be relied on, and > it's not a good argument for /bin and /sbin separation. So you have just argued that to hide things from autocompletion, one should make things 0700. We have also established that for this scheme to work the shell needs to do a stat() *for* *each* *candidate* executable. But the my /bin/bash does not do a stat() - which is sensible, cause that would be slow. And I couldn't parse if your zsh does or does not. So your proposed solution does not work for most users. So then you say one shouldn't rely on the autocompletion, because your advice (of merging /bin, /sbin and then marking user-uninteresting executables 0700) will make that mechanism unreliable, where it was quite reliable before. So your solution breaks autocompletion. > >Also on paranoid systems /sbin and /usr/sbin can itself be made 0700 or > >0750, so that random users can't even work out what admin commands might > >be there (hide suid exploits) > > I don't support security through obscurity, and you shouldn't either. Security through obscurity is a term often misunderstood. It states that knowledge of the implementation should not allow one to break the access control/restriction. The example I listed does none of the above. Here are the steps: * You have say a setgid executable which probably isn't perfectly secure. You trust your admin crowd to run it, but maybe not a php script which has escaped apache. * So you put it into /usr/sbin and do chmod 750 /usr/sbin chgrp admin /usr/sbin * And now if an exploit for said setgid tool becomes available then the php script won't be able to run it. There is no knowledge of how this mechanism works which would allow an attacker to bypass it. And in general, the R bit on files is there to hide data. If you confuse that with obscurity then there would be no confidentiality at all (and confidentiality, along with availability and integrity are what make up security). > >Or /sbin can be deleted/omitted entirely on containers/virtual images > >where all admin has been done already. > > People who tailor images with exactly the binaries they need will do > it regardless of the location of those binaries. Note I didn't say exactly, I implied it was a cheap option to give cp/tar/rsync to not build the full image and thereby improve the security and reduce the size of the image. Selecting packages and files individually is a lot more effort. Think about /sbin as a "tag" on the executable saying "probably not interesting to a normal user". This information isn't kept elsewhere, and so automating this by other means isn't that easy. > If you don't need > /sbin/route, you probably don't need /bin/mount either. Mount has an excuse to be a run by a user, given that fstab supports the "user" mount option. If that is a good idea or not is unclear. But this discussion relates to the quality and assignment of the tag "not interesting to a normal user", you are arguing for abolishing that tag entirely. More meta-information under your own (not corporate/government ;-) control is typically a good thing, especially if it has been compiled already. Assume that we merge bin and sbin: Chances are in some years some clever spark will then abuse posix labels to tag executables as "for admin (historic sbin)" and everybody will think this is a big breakthrough. > >So there are very good reasons for keeping the classic/standard layout. > > The reasons you gave so far are pretty minor. I listed concerns relating to autocompletion and security which are important to me regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status updates
Hello > * I then argue that in the current world, autocompletion is not > reliable, because since it does not stat(), it cannot hide filenames > the user cannot execute, such as a 0644 file. What your autocompletion > is currently printing is an approximation of the programs you can run, > not an accurate list - in other words, merging /bin and /sbin would not > "break" autocompletion, because it is already "broken". You are just > not seeing it because the (good) convention of not putting anything > non-executable in /bin is widely followed - but the whole mechanism > is simply relying on a convention, and stricto sensu you should not > entirely trust it. So ultimately everything in the computer world is just a convention. It is just convention that stat() gives you real filesystem permissions - strictly speaking you should first check the kernel source, that nobody has broken that, and then the hardware underneath that too. But snark aside, maybe view that these things are just conventions allows you to argue that they should be changed easily, while my position is that many things (like the shell) do rely on them being that way, and then won't work (or work as well) if they are changed. If they are called conventions, rules or laws doesn't make that much difference. > >* You have say a setgid executable which probably isn't perfectly > > secure. You trust your admin crowd to run it, but maybe not > > a php script which has escaped apache. > > > >* So you put it into /usr/sbin and do > > > > chmod 750 /usr/sbin > > chgrp admin /usr/sbin > > > >* And now if an exploit for said setgid tool becomes available > > then the php script won't be able to run it. > > OK, thanks for clarifying. This isn't security through obscurity > indeed. However, you could achieve the exact same result by putting > this tool in /usr/bin - or anywhere else - with chown root:admin > and chmod 2750 - you don't need a separate directory to hold binaries > you only want a specific group to run. No, sorry. Doing chown root:admin && chmod 2750 does not give anybody in the admin group (the ones who should be allowed to run it) any extra rights - they are already running with admin group privileges - setgid would be used to grant controlled access to another group (like disk, dialout, mail, etc, etc). So I think I understand your desire to clean things up, rationalise them - but the thing is that everybody uses a classical unix system in a slightly different way - a feature that is considered antiquated by some is essential to others, so these structures should change slowly and in a backward compatible manner. There are lots of examples of that, eg vim is a superset of vi, and in vim you can still drop down to ex mode which is the successor to ed. Maybe to use a sentimental analogy: A city with layers of history is much more rich/interesting and often more liveable than somewhere which has been bulldozed flat and centrally planned by a funky architect. In this regard systemd is so irritating since it demolishes so much established code to be replaced with something which I think is likely to spald and leak in a few years time :) regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Readiness notification
> For months, literally, the supervision list > has been wringing its hands over the very real problem that, for process > dependency purposes, one must know that process X is not only running, > but ready to handle its business. Knowing process X is running isn't > sufficent, because some processes take a long time between running > and being ready for business. At the risk of sounding like a broken record, this problem has been known for decades, and has been solved for decades (eg, see the sysklogd sources). The trick is for the daemon process to only background when it is ready to service requests (ie its parent process exits when the child is ready). And I am pretty sure I did (apologies for the repeated spam) mention my writeup at welz.org.za/notes/on-starting-daemons.html on this very list. It even contains a bit of sample code to reduce things to a single function call, and later a close() to stderr Actually, looking at the devuan archives, I actually mentioned it in a reply to you - not sure if this is sad or funny. regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] "Stretch" plans
> > > > > - Devuan Beowulf will be the next testing, and will follow Ascii > > > > > > > > You do realize issues when talking about this on Slashdot, naked and > > > > petrified? > > > > > > I am evidently missing something, but I can't see what. > > > > That particular release might be deemed particularly suitable for > > clustering applications ... > > I presume you mean the release name, not the release. Calling out next > testing release "beowulf" might be confusing. That might be better name > for *any* Devuan thats designed to make a cluster. So wed end up with > a jessie beowulf, an ascii beowulf, nd so forth. That was exactly Adams point/joke - any linux hardware advance had a "imagine a beowulf cluster of those" in the comments somewhere regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
> The surviving Devuan core team members will take zero or > more steps to prove Devuan trustworthy and sysadmins will > each decide for themselves or with their lawyers whether > they can continue to use Devuan. Weirdly enough I trust devuan a bit more after this incident: - I now know that the devuan servers are run by a very small team. Small is good. I now know that there isn't a humorless communications, legal or hr department which can overrule public facing communications. That is good for the longevity of the project, as it means the odds of it staying fun for longer are better. Too many procedures cause necrosis. Also: there is somebody who has the inclination and ability to build a complex technical prank. That means that somebody sees this as more than just a job and has some technical and time reserves. - This event has had more than one person think about what would happen if devuan were really compromised. How would you have restored/rolled back your systems ? So instead of complaining about a bad joke, consider it a dress-rehearsal for a real compromise. Is it worth the effort to keep a many month old copy of devuan sources offline, as a starting point for recovery from a catastrophic compromise ? Should you pick a few packages and mirror their upstream sources ? Can you even build a package from source - if not might it not be worth understanding how ? If you aren't thinking about these things now, then you aren't taking security seriously. This is not to say that the prank had problems: When confronted with somebody asking on April 1st: "is this really true, were you compromised ?" one doesn't answer "yes, we are investigating". One either fesses up or tries to strech credulity beyond breaking: "Yes we are investigating, and there is this green light shining from server rack. It turns the hackers aren't just wearing green hats, they are totally green and rather little - we are negotiating with them at the moment for access to our leader. Must be this time of year again..." regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Zoom? Rather not...
> I understand the security advantages of using zoom on a laptop not > much used for anything else. I suppose the sercurity conern is files > being accessible to intruders. Someone made the interesting suggestion > of settin up a new account just for zoom. The concern about using any gratis commercial videoconferencing service is that quite a bit of biometric information can be collected from you - in particular your voice and your face. Your personal files are just a bonus. Recall a while ago some company called clearview.ai made the news - given a picture of a person it finds all the other photos of that person online, and does a good job of it too. Any videoconferencing service is remarkably well positioned to generate an excellent facial model of you - given that there is a bit of motion and much data of you staring at the camera, a high-quality 3D model of your face can be constructed easily. This biometric information can be abused in so many ways, most of which are still to be invented. But recall the cambridge analytica scandal. It was supposed to have used rubbish online personality quizzes to generate custom ads to fix elections and referenda - with some success. Reportedly it is the reason brexit actually happened ... Now instead of having to rely on "do you like cats or dogs", the propaganda developers get to actually check out your microexpressions and changes in voice pitch... while A/B testing their evil on you. Anyway, if you value your free will then not using closed source video conferencing systems is a must. Similarly if you value your ability enter a store without hostile marketing logic giving you digital patdown... Remember the occasional news article showing off the big chinese control centres monitoring the cameras in some far away city, with a neat little onscreen name following every person walking down the street ? Odds are quite good that your video conferencing use will make it possible to add your name to that list. Some people are going to say "not possible, the call is end-to-end encrypted". Actually no. Illustrative example: The intercept reported that zoom claimed end-to-end encryption, but instead had one shared key, and used ECB (a really poor way of using a cypher). That is why it works so well, as a single lost packet doesn't garble the rest of the stream. More importantly, unlike Balsamic Vinegar or Zero Percent Fat, there is little enforcement of what these terms mean, and governments are keen to weaken encryption further. So if you ever hear "end-to-end video encryption" it is wise to assume "encrypted from your end to their data centre end". It is fashionable to use zoom as an example, given their strong connections to mainland china, but odds are excellent that this is happening on services too, where it is probably done better and more discretely. It is probably also the reason why tiktok is in the news regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] measure memory usage
> On Friday 21 August 2020 at 22:23:16, Hendrik Boom wrote: > > > Is there a way for process to ask about its own memory usage? > > Assuming the process knows its own PD, try the 24th value in /proc/PID/stat ... or just /proc/self/stat regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
