Re: Paquetes snap sin snap.

[Aradenatorix Veckhôm Avecælus]

Hola:

Como tampoco me gusta snap ni flatpak, una solución para mí a esto, además
de lo que comenta N4ch0, ha sido usar AppImage. Tiene la bondad de que
solamente se ejecuta cuando hace falta, algunos se pueden actualizar y si
no quieres que ocupen espacio en disco duro, puedes tenerlos almacenados en
un pendrive USB.
Desafortunadamente, no todos los programas que encuentras en snap o flatpak
cuentan con versión en AppImage. Pero me parece una opción interesante a
contemplar.

Saludos

Re: Paquetes snap sin snap.

[N4ch0]

On Thu Mar 28, 2024 at 2:59 PM -03, JavierDebian wrote:
> Buenas tardes.
>
> Proyecto para mi fin de semana:
>
> Instalar paquetes de SNAP sin instalar Snap.
> Odio Snap.
>
> ¿Alguien tiene alguna idea o intentó algo?
>
> Saludos

Buenas!

La pregunta sería que aplicación es para que debas usar snap? por mi
parte evito al 100% snap y flatpack o como se llame, jamás lo usé ni pienso, 
sino
exite el .deb bajo las fuentes y lo compilo.

Re: alsa en veille ?

[le père Léon]

Le 24/03/2024 à 09:57, Fabien R a écrit :

On 23/03/2024 16:48, le père Léon wrote:
Ton problème semble venir de cette ligne:
  AUDIOOUT: [AO_ALSA] alsa-lib: pcm_hw.c:1711:(snd_pcm_hw_open) open 
'/dev/snd/pcmC0D0p' failed (-16): Device or resource busy

Y-a-t-il d'autres applis ouvertes utilisant la carte son ?


A priori non, c'est justement quand rien ne s'est passé depuis longtemps 
que ça semble se produire.


--
Léon.

Re: making Debian secure by default

[Jeffrey Walton]

On Thu, Mar 28, 2024 at 5:07 PM Lee  wrote:
> [...]
> > A more proactive endeavor would be to document known best practices
> > on the wiki.  A quick search found a couple pages that might serve
> > as starting points:
> >
> > https://wiki.debian.org/SecurityManagement
> > https://wiki.debian.org/Hardening  -- says it's for package maintainers
> >
> > Anyone who is serious about such a project probably has a long road ahead
> > of them.
>
> Is there a generally preferred web link checker program for Debian?
> I took a look at
>   https://www.debian.org/doc/manuals/securing-debian-manual/ch04s15.en.html
> and the 4.15. Protecting against buffer overflows section has this bit:
> recompile the source code to introduce proper checks that prevent
> overflows, using the
>  http://www.research.ibm.com/trl/projects/security/ssp/ patch for GCC
> (which is used by
>  http://www.adamantix.org)
>
> http://www.research.ibm.com/trl/projects/security/ssp/ patch gives me
> a connect failed and
> http://www.adamantix.org sends me to a vietnamese tv site??
>
> Seems to me that an easy first step would be to check that all the
> links still work.

Wikipedia changes links to the Wayback Machine once a link goes bad.

Jeff

Re: making Debian secure by default

[debian-user]

 wrote:

> [1] https://xkcd.com/1200/

Here in the UK the most important part of that xkcd for most people
simply isn't true. Anything financial has a separate login procedure
and all that I use time out after a period of inactivity (even some
stupid non-important government things). I expect the same is true in
Europe? And I'd be surprised if it isn't true in Murrica too?

So a thief would have to be very lucky! Especially in my case since I
don't own a laptop and never use a phone or suchlike for financial
matters.

Re: making Debian secure by default

[Michael Kjörling]

On 28 Mar 2024 20:30 +, from dnomh...@gmx.com (Richmond):
> I always thought it strange that debian has no firewall on by
> default. Why not offer to enable one during installation? Opensuse
> offers to enable one and offers to allow ssh.

That sounds like a good idea to file as wishlist against
debian-installer.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 4:07 PM Andy Smith  wrote:
>
> Hi,
>
> On Thu, Mar 28, 2024 at 12:22:57PM -0400, Lee wrote:
   ... snip ...
>
> Documentation and integration is perpetually out of date in Linux.

Right.  Intellectually I know that; emotionally I find it a bit
difficult to accept.

> Also no one can agree on which documentation is canonical,

another area I'm struggling to accept.  Seeing referrals to the Arch
wiki on a debian mailing list just seems wrong..

> > Is there really nothing better than sudo find /  > files with uid or gid perms> and try to figure out which of those
> > program are not necessary?
>
> I don't think there is, no. After finding each of those things you
> would need to do some research on each one.

Right.  That's what I was trying to avoid.

> Those that are
> particularly worrisome probably already do have some notes
> somewhere.
>
> > $ sudo crontab -l
> >...
> >  47  4  *  *  *  (apt update >> apt-update.log 2>/dev/null) && \
> >   (apt list --upgradable 2>/dev/null |\
> >   egrep -v '^Listing' >| /etc/motd)
>
> You may like to look in to "apticron-systemd" for a systemd timer
> that does the above.

Nope.  I can't remember what I asked on this list years ago, but I got
a few suggestions on how to be notified about software updates and
ended up writing my own script.  If nothing else, I trust it to work
properly.
I also trust that if there's a problem with my script someone will let
me know :)

Thanks,
Lee

Re: making Debian secure by default

[Michael Kjörling]

On 28 Mar 2024 15:28 -0400, from g...@wooledge.org (Greg Wooledge):
>> so apparently somebody else has done a threat analysis and decided
>> apparmor is the appropriate mitigation strategy?
> 
> *An* appropriate mitigation strategy.  Not "the".
> 
> There are many, many layers.

Right. We've got everything from address space layout randomization
(ASLR), firewalling, full-disk encryption (for example with LUKS) and
automatic system updates all the way to password policies,
file/directory access permissions and system call masking. There is
the concept of data backups, storage-level redundancy, SMART
monitoring and system log analysis. It's possible to choose between
encrypted SSH and plain-text telnet or rsh for remote shell access
(and these days, no one should suggest the latter, but I digress).
Each of which can help mitigate _some_ threats and is utterly useless
against others.

Even within each of those there are differences. For example, a _lot_
of people and guides say, essentially unconditionally, "Thou Shall
Disable SSH Password Authentication". That's good advice in some
situations and _horrible_ advice in other situations.

It's not particularly meaningful to make a threat assessment for
"Debian". (It might very well be meaningful to make a threat
assessment for _the Debian project_, but that's something very
different.) What certainly _is_ meaningful is to make a threat
assessment for your computer, your data, your network and your usage.

Which will almost certainly be very different from mine, or Alice's,
or Bob's; never mind between my desktop system, Carol's server and
Mallory's laptop; and therefore will require a different
implementation.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: making Debian secure by default

[Richmond]

Lee  writes:

>
> oof.  Are there instructions somewhere on how to make Debian secure by
> default?
>
> Thanks, Lee

I always thought it strange that debian has no firewall on by
default. Why not offer to enable one during installation? Opensuse
offers to enable one and offers to allow ssh.

Re: VMs Windows, qual virtualizador é melhor?

[Glauber GF]

Fala aí mano...

Então, eu uso o Virt-Manager (KVM) que é bem melhor que o Virtual Box. Tenho 
algumas VMs aqui tanto de Linux como se Windows e não tenho o que reclamar.

Instale o Virt-Manager e seja feliz, rs!

Abraço.

Obter o Outlook para Android

From: hamacker 
Sent: Thursday, March 28, 2024 10:09:25 AM
To: Lista Debian 
Subject: VMs Windows, qual virtualizador é melhor?

Olá Pessoal,

Antes quando era php, eu usava apenas meu notebook com linux puro sangue,
Daí tive que trocar de trabalho, e daí fui linux em servidores, mas também 
programo e nesta empresa é Delphi e por causa disso, meu desktop é um Windows.
Mas recentemente, consegui autorização para usar Linux no meu desktop e apenas 
por causa do Delphi e coisas do MSSQL Server, vou precisar usar uma VM Windows.
Eu usei muito bem o virtualbox no passado quando precisei do Windows no meu 
notebook, mas como já faz tempo que não virtualizo nada no meu desktop, 
gostaria de saber de vocês se o VirtualBox ainda é o melhor para virtualizar 
Windows.

[] ´s

Re: making Debian secure by default

[David Wright]

On Thu 28 Mar 2024 at 12:36:56 (+0100), Emanuel Berg wrote:
> Michael Kjörling wrote:
> 
> >> "Secure by default" is an OpenBSD slogan BTW. Or they have
> >> made it into one at least. But I'm not sure it is any more
> >> secure than Debian - maybe.
> >> 
> >>   https://www.openbsd.org/security.html
> >
> > If I'm not mistaken, OpenBSD is "secure by default" by being
> > "extremely minimalistic by default".
> >
> > Last I looked, which in fairness was a while ago, a default
> > installation of OpenBSD includes almost nothing that normal,
> > present-day users would expect to find on their system. [...]
> 
> Ah, surely it can't refer to that as that would be completely
> ridiculous as it would imply "wanna install stuff? sure, but
> then it isn't secure anymore".

It's not clear what "isn't secure anymore" means. But anyway,

 “"Secure by Default"

 “To ensure that novice users of OpenBSD do not need to become
  security experts overnight (a viewpoint which other vendors seem to
  have), we ship the operating system in a Secure by Default mode.
  All non-essential services are disabled. As the user/administrator
  becomes more familiar with the system, he will discover that he has
  to enable daemons and other parts of the system. During the process
  of learning how to enable a new service, the novice is more likely
  to learn of security considerations.”

from https://www.openbsd.org/security.html
OTOH:

 “There are many applications one might want to use on an OpenBSD
  system. To make this software easier to install and manage, it is
  ported to OpenBSD and packaged. The aim of the package system is to
  keep track of which software gets installed, so that it may be easily
  updated or removed. In minutes, a large number of packages can be
  fetched and installed, with everything put in the right place.

 “The ports collection does not go through the same thorough security
  audit that is performed on the OpenBSD base system. Although we
  strive to keep the quality of the packages high, we just do not have
  enough resources to ensure the same level of robustness and
  security.”

from https://www.openbsd.org/faq/faq15.html (Package Management).

Cheers,
David.

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 2:32 PM Andy Smith  wrote:
>
> Hello,
>
> On Thu, Mar 28, 2024 at 11:24:08AM -0400, Greg Wooledge wrote:
> > On Thu, Mar 28, 2024 at 01:30:32PM +, Andy Smith wrote:
> > > https://www.debian.org/doc/manuals/debian-handbook/
> > >
> > > This has a chapter on security, so possibly it would be appropriate
> > > to mention "m,esg n" there.
> >
> > A more proactive endeavor would be to document known best practices
> > on the wiki.
>
> Personally I'll read the handbook before the wiki, but I'm fairly
> confident that the vast majority of users will read neither. 
>
> Which leads me to ask OP which hardening documents have they
> actually already read, and would the advice be suitable for those?

Read and understood?  None

I have looked at the Debian Administrator's Manual and the Securing
Debian Manual.  I'll bet not enough has sunk in though.

Years ago, I had to do CIS router security benchmarks for work so I
know what went into a network security analysis & how much background
knowledge was necessary to implement the policy ..  Which is why I'm
_sure_ I don't have enough background knowledge to do an adequate
threat analysis for a Debian machine.

I guess I'm just lazy :)  and looking for a short-cut instead of doing
the hard work and figuring it out for myself.

Regards,
Lee

Re: making Debian secure by default

[tomas]

On Thu, Mar 28, 2024 at 03:23:48PM -0400, Lee wrote:

[...]

> I disagree.  I don't think I'm qualified to make an adequate threat
> analysis for a Debian system and yet

Nobody is. The threat analysis for my virtual server "out there" is
totally different (sshd, exim, http(s), git running on external ports,
yadda, yadda), but running 24/7 in some physically protected data
center; for my laptop, most of the time behind a firewall, but running
a web browser *and* phisically insecure (can be stolen/left behind).

So in the first case it makes sense to focus on network hardening,
whereas disk encryption is an unnecessary hassle (ever tried to boot
from a LUKS disk remotely? Yes, I know it /can/ be done). In the
second case disk encryption is a /must/ (as it is to keep up to date
with it).

How would you make a threat analysis "for Debian"? That makes no
sense. The only you can do is to document the security properties of
each and every component and use that as a toolkit for your particular
use case.

Security, as Bruce Schneier [1] says, is a process. Not a product.

Cheers

[1] https://www.schneier.com/
-- 
t


signature.asc
Description: PGP signature

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 1:48 PM Curt wrote:
>
> On 2024-03-28, Greg Wooledge wrote:
> >
> > A more proactive endeavor would be to document known best practices
>
> It makes no fucking difference, because your important data is elsewhere
> and completely out of your control.

Agreed - your important data is elsewhere and completely out of your
control.  But I don't think that's a good reason to quit trying.

Regards,
Lee

Re: making Debian secure by default

[Greg Wooledge]

On Thu, Mar 28, 2024 at 03:23:48PM -0400, Lee wrote:
> so apparently somebody else has done a threat analysis and decided
> apparmor is the appropriate mitigation strategy?

*An* appropriate mitigation strategy.  Not "the".

There are many, many layers.

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 1:28 PM tomas wrote:
>
> On Thu, Mar 28, 2024 at 12:22:57PM -0400, Lee wrote:
> > On Thu, Mar 28, 2024 at 1:11 AM tomas wrote:
>
> [...]
>
> > > Security means first and foremost understanding the threat.
> >
> > Which I don't.  Hence the request for 'secure by default' instructions
> > for Debian.  Even better would be a secure by default installation
> > option.
>
> This makes little sense. No threat analysis -- no security. Security
> is always a relative (to the threat model) term, "security by default"
> suggests something absolute. This ain't going to work.

I disagree.  I don't think I'm qualified to make an adequate threat
analysis for a Debian system and yet
  $ sudo aa-status
  apparmor module is loaded.
  21 profiles are loaded.
  19 profiles are in enforce mode.
 ...
  6 processes are in enforce mode.

so apparently somebody else has done a threat analysis and decided
apparmor is the appropriate mitigation strategy?

I'm coming to the realization that more is wishful thinking, but
still.. it would be nice if I didn't feel like I was facing such an
overwhelmingly steep learning curve.

Regards,
Lee

Re: VMs Windows, qual virtualizador é melhor?

[Atenágoras Silva]

A Borland havia feito uma versão do Delphi para GNU/Linux... Ainda usam
Delphi?
Há muitas opções para você fazer isso, e algumas delas não depende de
virtualização. (embora o virt-manager torne a virtualização com o kvm
absurdamente fácil)
- É possível usar o ReactOS (Sistema Operacional compatível com o Windows,
mas com licença livre) no KVM ou no virtualbox
- Dá para usar Delphi no wine
- Existe uma IDE chamada Lazarus, que tem licença GPL, e que pode
substituir o Delphi, de modo que talvez seja possível você nem precisar de
virtualização nem de uma camada de compatibilidade com o Windows.

Boa sorte!

Em qui., 28 de mar. de 2024 às 13:54, Glauber GF 
escreveu:

> Na instalação ele já instala as dependências necessárias... Caso contrário
> tem vc instala tbm o virtmanager-guest.
>
> Instala virt-manager e faça um teste, não irá se arrepender.
>
> Obter o Outlook para Android 
>
> --
> *De:* hamacker 
> *Enviado:* quinta-feira, março 28, 2024 12:56:39 PM
> *Para:* Glauber GF 
> *Cc:* Lista Debian 
> *Assunto:* Re: VMs Windows, qual virtualizador é melhor?
>
> O kvm precisa de alguma ferramenta de guest como o virtualbox? sem o
> guest(ferramenta para convidado), o virtualbox faz fullvirtualization, daí
> fica meio capenga.
>
> Em qui., 28 de mar. de 2024 às 12:05, Glauber GF 
> escreveu:
>
>> Fala aí mano...
>>
>> Então, eu uso o Virt-Manager (KVM) que é bem melhor que o Virtual Box.
>> Tenho algumas VMs aqui tanto de Linux como se Windows e não tenho o que
>> reclamar.
>>
>> Instale o Virt-Manager e seja feliz, rs!
>>
>>
>

Re: making Debian secure by default

[Lee]

> Hope this helps a little bit.

Yes, it does.  I was hoping for something simple but it's becoming
clear to me that there's no simple "make Debian secure for dummies"
checklist to follow.

Thanks,
Lee


On Thu, Mar 28, 2024 at 11:43 AM Hans wrote:
>
> Hello,
> personally I think, the best way is to plan, what you want to do with your
> system. What is its task. How secure it shall be.
>
> And then just think of: What can happen? For example: Can someone boot wirt an
> external medium? Do more than one people got admin rights? How do people
> access? Can the server be stolen? And so on.
>
> Make a list, do brainsorming with other people. Learn from other hacks.
>
> And then act for every point you made. Think, how can this and this and this
> attack be inhibited, how can it be noticed and is there an alarm and so on.
>
> For my personal experience, I never saw an attack in the past, which was not
> prepared. Before are runninng portscans or simple bruteforce attacks.
>
> Here I am talking of activists and script kiddies, not APT's. APT's are much
> more difficult to defend and to discover, they can, but very, very difficult.
>
> A good point to start is the doc "securing debian", and then, after you did
> this, think of, what you have forgotten and what did the docu not tell.
>
> IT-Security is no software, it is a process, and you will have to learn for
> years, which is normal. The attackers learn, the defenders, too.
>
> There is no straight, golden way, every server is different, and so are its
> defence. As I said, its a concept, and this can change during the years.
>
> Hope this helps a little bit.
>
> Best regards
>
> Hans

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 11:24 AM Greg Wooledge  wrote:
>
> On Thu, Mar 28, 2024 at 01:30:32PM +, Andy Smith wrote:
> > I'm just not sure that you'll find any "hardening" guide that will
> > specifically say "disable writing to your terminal as there might be
> > a bug in a binary that is setgid tty" before yesterday's reveal that
> > there is such a bug in "wall".
> >
> > The more general advice to audit every setuid/setgid binary is more
> > likely to be present.
> [...]
> > If the maintainer of util-linux doesn't agree, then the next thing
> > I'd try is a bug against the Debian Administrator's Handbook:
> >
> > https://www.debian.org/doc/manuals/debian-handbook/
> >
> > This has a chapter on security, so possibly it would be appropriate
> > to mention "m,esg n" there.
>
> A more proactive endeavor would be to document known best practices
> on the wiki.  A quick search found a couple pages that might serve
> as starting points:
>
> https://wiki.debian.org/SecurityManagement
> https://wiki.debian.org/Hardening  -- says it's for package maintainers
>
> Anyone who is serious about such a project probably has a long road ahead
> of them.

Is there a generally preferred web link checker program for Debian?
I took a look at
  https://www.debian.org/doc/manuals/securing-debian-manual/ch04s15.en.html
and the 4.15. Protecting against buffer overflows section has this bit:
recompile the source code to introduce proper checks that prevent
overflows, using the
 http://www.research.ibm.com/trl/projects/security/ssp/ patch for GCC
(which is used by
 http://www.adamantix.org)

http://www.research.ibm.com/trl/projects/security/ssp/ patch gives me
a connect failed and
http://www.adamantix.org sends me to a vietnamese tv site??

Seems to me that an easy first step would be to check that all the
links still work.

Regards,
Lee

Paquetes snap sin snap.

[JavierDebian]

Buenas tardes.

Proyecto para mi fin de semana:

Instalar paquetes de SNAP sin instalar Snap.
Odio Snap.

¿Alguien tiene alguna idea o intentó algo?

Saludos

Re: making Debian secure by default

[Curt]

On 2024-03-28, Greg Wooledge  wrote:
>
> A more proactive endeavor would be to document known best practices

It makes no fucking difference, because your important data is elsewhere
and completely out of your control.

Re: making Debian secure by default

[tomas]

On Thu, Mar 28, 2024 at 12:22:57PM -0400, Lee wrote:
> On Thu, Mar 28, 2024 at 1:11 AM tomas wrote:

[...]

> > Security means first and foremost understanding the threat.
> 
> Which I don't.  Hence the request for 'secure by default' instructions
> for Debian.  Even better would be a secure by default installation
> option.

This makes little sense. No threat analysis -- no security. Security
is always a relative (to the threat model) term, "security by default"
suggests something absolute. This ain't going to work.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: making Debian secure by default

[Florent Rougon]

Le 28/03/2024, Greg Wooledge  a écrit:

> You can't stop root from writing to your terminal.  Root has write
> privileges on all devices.
>
> The purpose of mesg is to allow *other regular users* to send you
> messages, or not. (...)

Indeed, I understood that after running 'ls -la $(tty)', as suggested
elsewhere by Andy. Thanks for the complement and all your useful
messages.

Regards

-- 
Florent

Re: making Debian secure by default

[Andy Smith]

Hi,

On Thu, Mar 28, 2024 at 12:22:57PM -0400, Lee wrote:
> For heavens sake, the man page says
> 
>Traditionally, write access is allowed by default.  However,  as  users
>become  more  conscious  of various security risks, there is a trend to
>remove write access by default, at least for the primary  login  shell.
>To  make  sure  your ttys are set the way you want them to be set, mesg
>should be executed in your login scripts.
> 
> Clearly at least the man page writer realized there was a threat there
> _and chose not to remove the threat_ !?

For context, that was likely written by someone a decade or more
ago, someone who did not have responsibility for any other part of
Linux. Since that time even the parts that were in charge of setting
terminal permissions might have changed implementation and
maintainers several times.

It's not that they chose not to keep the rest of the system
consistent with their opinion, it's more likely that they could not.

Documentation and integration is perpetually out of date in Linux.
Also no one can agree on which documentation is canonical, and very
few people read any of it. I'm just as guilty as anyone: having no
use for "wall" or "mesg" for decades, I hadn't read its man page and
didn't notice that terminals were group-writeable.

> Is there really nothing better than sudo find /  files with uid or gid perms> and try to figure out which of those
> program are not necessary?

I don't think there is, no. After finding each of those things you
would need to do some research on each one. Those that are
particularly worrisome probably already do have some notes
somewhere.

> $ sudo crontab -l
>...
>  47  4  *  *  *  (apt update >> apt-update.log 2>/dev/null) && \
>   (apt list --upgradable 2>/dev/null |\
>   egrep -v '^Listing' >| /etc/motd)

You may like to look in to "apticron-systemd" for a systemd timer
that does the above. (drop the "-systemd" if you prefer a cron job
equivalent)

apticorn is mentioned in the Debian Administrator's Handbook which
is worth a read even though it only covers up to Debian 11.


https://www.debian.org/doc/manuals/debian-handbook/sect.regular-upgrades.en.html

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: making Debian secure by default

[Greg Wooledge]

On Thu, Mar 28, 2024 at 05:23:36PM +0100, Florent Rougon wrote:
> Did anyone try 'mesg n' here? I tried:
> 
> 
> $ mesg n
> $ mesg; echo $?
> is n
> 1
> 
> Broadcast message from root@hostname (pts/1) (Thu Mar 28 16:48:13 2024):
> 
> pouet

You can't stop root from writing to your terminal.  Root has write
privileges on all devices.

The purpose of mesg is to allow *other regular users* to send you
messages, or not.  People have focused so much on "wall" in this
thread, but wall is usually used by root, or by the OS itself, to
send broadcast notices of major events like impending reboots.

The more common tool for users to talk to each other on their terminals
is write(1).  Or if you wanted to have a conversation, there's talk(1).
Or rather, there's supposed to be talk(1).  I have a POSIX man page
for it, but not a Debian one, and the program itself doesn't appear to
be installed.  Maybe it's in a separate package.

I have write(1) from the bsdextrautils package.  There is a talk package
but I haven't installed it.

Re: making Debian secure by default

[Florent Rougon]

Le 28/03/2024, Florent Rougon  a écrit:

> Did I miss the point of 'mesg n'?..

Ugh, sorry. Thanks to the 'ls -la $(tty)' command Andy Smith wrote in
another message, I understood:

  'mesg n' does prevent users from writing to your terminal using e.g.
  'wall', *except* if said users are either root or yourself.

So I redid the above test but using 'wall' from *another* non-root
account: 'mesg n' did prevent the messages from coming through, and
'mesg y' allowed them again.

All good. :-)

Regards

-- 
Florent

Re: VMs Windows, qual virtualizador é melhor?

[Glauber GF]

Na instalação ele já instala as dependências necessárias... Caso contrário tem 
vc instala tbm o virtmanager-guest.

Instala virt-manager e faça um teste, não irá se arrepender.

Obter o Outlook para Android


De: hamacker 
Enviado: quinta-feira, março 28, 2024 12:56:39 PM
Para: Glauber GF 
Cc: Lista Debian 
Assunto: Re: VMs Windows, qual virtualizador é melhor?

O kvm precisa de alguma ferramenta de guest como o virtualbox? sem o 
guest(ferramenta para convidado), o virtualbox faz fullvirtualization, daí fica 
meio capenga.

Em qui., 28 de mar. de 2024 às 12:05, Glauber GF 
mailto:glauber...@hotmail.com>> escreveu:
Fala aí mano...

Então, eu uso o Virt-Manager (KVM) que é bem melhor que o Virtual Box. Tenho 
algumas VMs aqui tanto de Linux como se Windows e não tenho o que reclamar.

Instale o Virt-Manager e seja feliz, rs!

Re: making Debian secure by default

[Andy Smith]

Hi,

On Thu, Mar 28, 2024 at 05:21:21PM +0100, Michel Verdier wrote:
> On 2024-03-28, Marc SCHAEFER wrote:
> >> Apparently the root of the security issue is that wall is a setguid 
> >> program?
> >
> > a) wall must be able to write to your tty, which is not possible
> >if wall is not installed setguid OR if people have sane permissions
> >on their terminals (e.g. set to mesg n)
> 
> Found in /etc/login.defs :

Is login.defs actually used by modern Debian with PAM? I seem to
recall lots of things in there are controlled by PAM instead now.

Looking at all of my sessions, the terminal file for all of them is
group writeable despite "TTYPERM 0600" being in /etc/login.defs.

$ ls -la $(tty)
crw--w 1 andy tty 136, 0 Mar 28 16:33 /dev/pts/0
$ mesg
is y
$ mesg n
$ ls -la $(tty)
crw--- 1 andy tty 136, 0 Mar 28 16:34 /dev/pts/0

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: making Debian secure by default

[Franco Martelli]

On 28/03/24 at 12:05, Marc SCHAEFER wrote:

Hello,

On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:

Apparently the root of the security issue is that wall is a setguid program?


a) wall must be able to write to your tty, which is not possible
if wall is not installed setguid OR if people have sane permissions
on their terminals (e.g. set to mesg n)

b) in addition, for this exploit to run, command-not-found must be
started with the not found command as argument: in the two Debian
releases I just tried (buster and bookworm), with bash,
command-not-found was not installed.

The idea of the exploit is that you get a prompt for entering a sudo
password, which is a simple text (which gets more convincing because
of a recently introduced bug in wall which does not filter out terminal
escape / control sequences), then you type the root password, which
is presumably not the name of an existing command, so command-not-found
PASSWORD is run, and someone on another terminal and user can do
a ps to see that password argument if he is quick or polling.

To fix this:

a) don't type a root password / sudo password unless you know that
it should happen

b) don't allow others to write on your terminals, in particular
if you run priviledged commands and expect sudo prompts

c) patch wall so that its texts are always shown to be
different from other program outputs (== filter out
anything else than printable characters)

THIS IS MY PREFERRED WORKAROUND :)
(mixing controls (prompts) and data is always
 a very bad idea)

d) don't have other users on your machine / use containers.


Do you know whether it exists a tutorial/wiki that explain how to avoid 
users in favor to containers?


Thanks in advance

--
Franco Martelli

Re: making Debian secure by default

[Florent Rougon]

Hi,

Le 27/03/2024, Andy Smith  a écrit:

> You could put a call to "mesg n" into a file in /etc/profile.d so
> that all users execute it.

Did anyone try 'mesg n' here? I tried:


$ mesg n
$ mesg; echo $?
is n
1

Broadcast message from root@hostname (pts/1) (Thu Mar 28 16:48:13 2024):

pouet


Broadcast message from simpleuser@hostname (pts/3) (Thu Mar 28 16:48:49 2024):

a



Did I miss the point of 'mesg n'?..

Thanks, regards

-- 
Florent

Re: making Debian secure by default

[Lee]

On Thu, Mar 28, 2024 at 1:11 AM tomas wrote:
>
> On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> > I just saw this advisory
> >   Escape sequence injection in util-linux wall (CVE-2024-28085)
> > https://seclists.org/fulldisclosure/2024/Mar/35
> > where they're talking about grabbing other users sudo password.
>
> Are there any users logged in to your computer you dont't trust?
>
> Thought so.
>
> Relax.
>
> Security means first and foremost understanding the threat.

Which I don't.  Hence the request for 'secure by default' instructions
for Debian.  Even better would be a secure by default installation
option.

To be clear, I'm not all that concerned about _this_ CVE.  I've got
the disable_mesg.sh file in /etc/profile.d so sending messages with
control codes to other terminals should be disabled for all.

My concern is all the other stuff that I don't even know about that
could be configured in a more secure manner but isn't.  For heavens
sake, the man page says

   Traditionally, write access is allowed by default.  However,  as  users
   become  more  conscious  of various security risks, there is a trend to
   remove write access by default, at least for the primary  login  shell.
   To  make  sure  your ttys are set the way you want them to be set, mesg
   should be executed in your login scripts.

Clearly at least the man page writer realized there was a threat there
_and chose not to remove the threat_ !?

So what other goodies are there that I don't know about?  Is there
really nothing better than sudo find /  and try to figure out which of those program are not
necessary?

And I'm still a bit surprised that needrestart isn't included as part
of the default install.  Or at least as part of the synaptic package
manager install.  I never guessed that I would _not_ be warned that I
needed to reboot after updating software with the synaptic package
manager -- that didn't happen until after I installed needrestart.

> Randomly
> reaching into the CVE box will most probably keep you from actually
> working on your real issues. E.g. your browser.

I think it's up to date:
$ cat /etc/motd

lee@spot ~
$ sudo crontab -l
[sudo] password for lee:
   ...
 47  4  *  *  *  (apt update >> apt-update.log 2>/dev/null) && \
  (apt list --upgradable 2>/dev/null |\
  egrep -v '^Listing' >| /etc/motd)

> Or your social media
> account.

I've never had one.

> Cheers
>
> [1] https://xkcd.com/1200/

I like the quote I saved from the full disclosure mailing list back
when it was fun & exploits were mailed out as attachments:

And at some point, you really have to ask yourself "Is this really a
plausible attack method, or did I forget to take my meds again?"
   -- Valdis Kletnieks

Regards
Lee

Re: making Debian secure by default

[Michel Verdier]

On 2024-03-28, Marc SCHAEFER wrote:

>> Apparently the root of the security issue is that wall is a setguid program?
>
> a) wall must be able to write to your tty, which is not possible
>if wall is not installed setguid OR if people have sane permissions
>on their terminals (e.g. set to mesg n)

Found in /etc/login.defs :

#
# Terminal permissions
#
#   TTYGROUPLogin tty will be assigned this group ownership.
#   TTYPERM Login tty will be set to this permission.
#
# If you have a "write" program which is "setgid" to a special group
# which owns the terminals, define TTYGROUP to the group number and
# TTYPERM to 0620.  Otherwise leave TTYGROUP commented out and assign
# TTYPERM to either 622 or 600.
#
# In Debian /usr/bin/bsd-write or similar programs are setgid tty
# However, the default and recommended value for TTYPERM is still 0600
# to not allow anyone to write to anyone else console or terminal

# Users can still allow other people to write them by issuing 
# the "mesg y" command.

TTYGROUPtty
TTYPERM 0600

My tty is set to 0600 and even with "mesg y" only root can send a message
with wall. Am I missing something ?

Re: VMs Windows, qual virtualizador é melhor?

[hamacker]

O kvm precisa de alguma ferramenta de guest como o virtualbox? sem o
guest(ferramenta para convidado), o virtualbox faz fullvirtualization, daí
fica meio capenga.

Em qui., 28 de mar. de 2024 às 12:05, Glauber GF 
escreveu:

> Fala aí mano...
>
> Então, eu uso o Virt-Manager (KVM) que é bem melhor que o Virtual Box.
> Tenho algumas VMs aqui tanto de Linux como se Windows e não tenho o que
> reclamar.
>
> Instale o Virt-Manager e seja feliz, rs!
>
>

Re: making Debian secure by default

[Andy Smith]

Hello,

On Thu, Mar 28, 2024 at 11:24:08AM -0400, Greg Wooledge wrote:
> On Thu, Mar 28, 2024 at 01:30:32PM +, Andy Smith wrote:
> > https://www.debian.org/doc/manuals/debian-handbook/
> > 
> > This has a chapter on security, so possibly it would be appropriate
> > to mention "m,esg n" there.
> 
> A more proactive endeavor would be to document known best practices
> on the wiki.

Personally I'll read the handbook before the wiki, but I'm fairly
confident that the vast majority of users will read neither. 

Which leads me to ask OP which hardening documents have they
actually already read, and would the advice be suitable for those?

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: making Debian secure by default

[Hans]

Hello,
personally I think, the best way is to plan, what you want to do with your 
system. What is its task. How secure it shall be.

And then just think of: What can happen? For example: Can someone boot wirt an 
external medium? Do more than one people got admin rights? How do people 
access? Can the server be stolen? And so on.

Make a list, do brainsorming with other people. Learn from other hacks.

And then act for every point you made. Think, how can this and this and this 
attack be inhibited, how can it be noticed and is there an alarm and so on.

For my personal experience, I never saw an attack in the past, which was not 
prepared. Before are runninng portscans or simple bruteforce attacks.

Here I am talking of activists and script kiddies, not APT's. APT's are much 
more difficult to defend and to discover, they can, but very, very difficult.

A good point to start is the doc "securing debian", and then, after you did 
this, think of, what you have forgotten and what did the docu not tell.

IT-Security is no software, it is a process, and you will have to learn for 
years, which is normal. The attackers learn, the defenders, too.

There is no straight, golden way, every server is different, and so are its 
defence. As I said, its a concept, and this can change during the years.

Hope this helps a little bit.

Best regards

Hans


  

Re: Filsystemkorruption i ext4?

[Hans]

Hi Jesper,

RAID 1 is mirroring. I suppose, a reason for the failure might be a timing 
problem. I do not know for sure, if yous system has got a real RAID-controller 
or if it is made by software.

The real controller should not produce write errors, however maybe at heavy 
load it might happen. I never used RAID 1 myself, as I am a fancy guy and am 
no friend of RAID 1. It is just, when there is an error on one drive, it is on 
the other, too.

My fancy solution was, using one drive and mirror this frequently every 30 
minutes using rsync. IMO doing so, I have several options:

1. If the harddrive is defective, I can boot the other one.

2. If the software is defective, I have 30 minutes, to discover the failure 
(every good logging system should alarm this in time)

3. I have a running backup available.

4. I can exchange the defective harddrive during the running system.

5. After exchange, i can examine, what happened (hardware failure, malware, 
whatever).

Many people will now laugh at me, but doing so, worked for me at best. So I 
reached an uptime of more than 700 days, but this might not be based on my 
work, but the work of all the debian developers!

As I said before, i am not very experienced with RAID 1, other people might 
know much more.

Personally I believe, RAID is mostly used with Windows, as Windows does not 
have these nice tools like rsync or syslog and all the things, that make linux 
and debian so great.

Have a nice eastern!

Best

Hans 

> Sorry - I should have left more of the previous mails quoted.  I have
> previously tested the RAID1 consistency (ok), fixed the file system
> (found 3 files with incorrect block count), and now also tested the
> RAM.And since it seems unlikely that it is a bug in ext4 (in Debian
> Bullseye), I don't quite understand how such an inconsistency can occur.
> Thanks for your response, Jesper
> 
> > If so, I suggest to boot a live system like Knoppix or similar, then run
> > your test by using
> > 
> > e2fsck -y /dev/sda1
> > 
> > or wherever your filesystem resides.
> > 
> > Please pay attention: If you have encrypted filesystems, then first open
> > the encryption, do NOT mount the filesystem and then check it, for
> > example:
> > 
> > cryptsetup luksOpen /dev/sda1 data1
> > 
> > then enter the password and now you can run
> > 
> > e2fsck -y /dev/mapper/data1
> > 
> > Note: the word "data1" is only an example, you can name it, whatever you
> > want like "space", "soap", "bullet", "henry" or whatever.
> > 
> > Hope this helps.
> > 
> > Best
> > 
> > Hans
> > 
> >> [Sorry - I accidentally sent this too quickly in an incomplete state.
> >> Second try here:]
> >> 
> >>> On Wed, Mar 20, 2024, 11:28 AM Jesper Dybdal
> >>> 
> >>>   wrote:
> >>>  I think I'll let memtest86+ run overnight one of the coming nights.
> >>>  
> >>>  Unless it is simply a RAM error, then it is a bit scary...
> >> 
> >> I've now let memtest86+ run for 9 hours, during which it did 14 passes
> >> of all its tests.  It found nothing wrong.
> >> 
> >> On 2024-03-20 22:58, Nicholas Geovanis wrote:
> >>> I have seen that a couple times, unlikely but possible. Maybe review
> >>> your RAM configuration too, ensure that the sticks are on the same
> >>> supported refresh rate and distributed across the slots in an approved
> >>> way.
> >> 
> >> There is only one RAM stick (of 16 GB), so there should be no problems
> >> of that kind.
> >> 
> >> I'm afraid I won't find an explanation of that file system corruption :-(
> >> 
> >> Thanks to Franco and Nicholas for your responses,
> >> Jesper

Re: making Debian secure by default

[Greg Wooledge]

On Thu, Mar 28, 2024 at 01:30:32PM +, Andy Smith wrote:
> I'm just not sure that you'll find any "hardening" guide that will
> specifically say "disable writing to your terminal as there might be
> a bug in a binary that is setgid tty" before yesterday's reveal that
> there is such a bug in "wall".
> 
> The more general advice to audit every setuid/setgid binary is more
> likely to be present.
[...]
> If the maintainer of util-linux doesn't agree, then the next thing
> I'd try is a bug against the Debian Administrator's Handbook:
> 
> https://www.debian.org/doc/manuals/debian-handbook/
> 
> This has a chapter on security, so possibly it would be appropriate
> to mention "m,esg n" there.

A more proactive endeavor would be to document known best practices
on the wiki.  A quick search found a couple pages that might serve
as starting points:

https://wiki.debian.org/SecurityManagement
https://wiki.debian.org/Hardening  -- says it's for package maintainers

Anyone who is serious about such a project probably has a long road ahead
of them.

Re: VMs Windows, qual virtualizador é melhor?

[Daniel Venturini]

Bom dia, pessoal.

Eu uso Linux 100% no meu desktop mas quando tenho que cobrir férias de um
colega de trabalho tenho que usar Windows para algumas tarefas.

Eu tenho um Windows 10 instalado sobre o KVM (e obviamente o VirtManager
como GUI). Esse Windows 10 executa perfeitamente e até tenho um antivírus
da empresa instalado nessa máquina Windows e por muitas vezes tenho q
compartilhar o acesso através do AnyDesk nesse Windows. O desempenho é bom,
e consigo até mesmo usar ambos sistemas (Linux no desktop e o Windows no
KVM) ao mesmo tempo.

O KVM é super estável para isso e eu recomendo.

On Thu, Mar 28, 2024, 11:12 AM Paulo Oliveira 
wrote:

> o virtualbox ainda continua sendo bom. mas tambem tens outras ocoes como
> o vmware e o kvm
>
> On 3/28/24 12:09, hamacker wrote:
> > Olá Pessoal,
> >
> > Antes quando era php, eu usava apenas meu notebook com linux puro sangue,
> > Daí tive que trocar de trabalho, e daí fui linux em servidores, mas
> > também programo e nesta empresa é Delphi e por causa disso, meu
> > desktop é um Windows.
> > Mas recentemente, consegui autorização para usar Linux no meu desktop
> > e apenas por causa do Delphi e coisas do MSSQL Server, vou precisar
> > usar uma VM Windows.
> > Eu usei muito bem o virtualbox no passado quando precisei do Windows
> > no meu notebook, mas como já faz tempo que não virtualizo nada no meu
> > desktop, gostaria de saber de vocês se o VirtualBox ainda é o melhor
> > para virtualizar Windows.
> >
> > [] ´s
>
>

Re: Filsystemkorruption i ext4?

[Jesper Dybdal]

On 2024-03-28 15:02, Hans wrote:

Am Donnerstag, 28. März 2024, 14:49:37 CET schrieb Jesper Dybdal:
Hello,

memtest86+ is for testing RAM, but do you not want to test ext4 filesystem?


Sorry - I should have left more of the previous mails quoted.  I have 
previously tested the RAID1 consistency (ok), fixed the file system 
(found 3 files with incorrect block count), and now also tested the 
RAM.And since it seems unlikely that it is a bug in ext4 (in Debian 
Bullseye), I don't quite understand how such an inconsistency can occur. 
Thanks for your response, Jesper

If so, I suggest to boot a live system like Knoppix or similar, then run your
test by using

e2fsck -y /dev/sda1

or wherever your filesystem resides.

Please pay attention: If you have encrypted filesystems, then first open the
encryption, do NOT mount the filesystem and then check it, for example:

cryptsetup luksOpen /dev/sda1 data1

then enter the password and now you can run

e2fsck -y /dev/mapper/data1

Note: the word "data1" is only an example, you can name it, whatever you want
like "space", "soap", "bullet", "henry" or whatever.

Hope this helps.

Best

Hans




[Sorry - I accidentally sent this too quickly in an incomplete state.
Second try here:]


On Wed, Mar 20, 2024, 11:28 AM Jesper Dybdal

  wrote:
 I think I'll let memtest86+ run overnight one of the coming nights.
 
 Unless it is simply a RAM error, then it is a bit scary...

I've now let memtest86+ run for 9 hours, during which it did 14 passes
of all its tests.  It found nothing wrong.

On 2024-03-20 22:58, Nicholas Geovanis wrote:

I have seen that a couple times, unlikely but possible. Maybe review
your RAM configuration too, ensure that the sticks are on the same
supported refresh rate and distributed across the slots in an approved
way.

There is only one RAM stick (of 16 GB), so there should be no problems
of that kind.

I'm afraid I won't find an explanation of that file system corruption :-(

Thanks to Franco and Nicholas for your responses,
Jesper






--
Jesper Dybdal
https://www.dybdal.dk

Re: making Debian secure by default

[Curt]

On 2024-03-28,   wrote:
>
> Security means first and foremost understanding the threat. Randomly

The threat here is that some pharmacist in the provinces falls for a
phishing email, gives black hats access to the system, and reveals my
sensitive data to these people who devised the alluringly convincing
electronic missive.

This is precisely what happened here in France not long ago to half the
population. The user of the French health-care system can do nothing to
obviate this threat. There is no remedy for the foibles of other men.

Re: VMs Windows, qual virtualizador é melhor?

[Paulo Oliveira]

o virtualbox ainda continua sendo bom. mas tambem tens outras ocoes como 
o vmware e o kvm


On 3/28/24 12:09, hamacker wrote:

Olá Pessoal,

Antes quando era php, eu usava apenas meu notebook com linux puro sangue,
Daí tive que trocar de trabalho, e daí fui linux em servidores, mas 
também programo e nesta empresa é Delphi e por causa disso, meu 
desktop é um Windows.
Mas recentemente, consegui autorização para usar Linux no meu desktop 
e apenas por causa do Delphi e coisas do MSSQL Server, vou precisar 
usar uma VM Windows.
Eu usei muito bem o virtualbox no passado quando precisei do Windows 
no meu notebook, mas como já faz tempo que não virtualizo nada no meu 
desktop, gostaria de saber de vocês se o VirtualBox ainda é o melhor 
para virtualizar Windows.


[] ´s

Re: Filsystemkorruption i ext4?

[Hans]

Am Donnerstag, 28. März 2024, 14:49:37 CET schrieb Jesper Dybdal:
Hello,

memtest86+ is for testing RAM, but do you not want to test ext4 filesystem?

If so, I suggest to boot a live system like Knoppix or similar, then run your 
test by using

e2fsck -y /dev/sda1

or wherever your filesystem resides. 

Please pay attention: If you have encrypted filesystems, then first open the 
encryption, do NOT mount the filesystem and then check it, for example:

cryptsetup luksOpen /dev/sda1 data1

then enter the password and now you can run

e2fsck -y /dev/mapper/data1

Note: the word "data1" is only an example, you can name it, whatever you want 
like "space", "soap", "bullet", "henry" or whatever.

Hope this helps.

Best

Hans



> [Sorry - I accidentally sent this too quickly in an incomplete state. 
> Second try here:]
> 
> > On Wed, Mar 20, 2024, 11:28 AM Jesper Dybdal
> > 
> >  wrote:
> > I think I'll let memtest86+ run overnight one of the coming nights.
> > 
> > Unless it is simply a RAM error, then it is a bit scary...
> 
> I've now let memtest86+ run for 9 hours, during which it did 14 passes
> of all its tests.  It found nothing wrong.
> 
> On 2024-03-20 22:58, Nicholas Geovanis wrote:
> > I have seen that a couple times, unlikely but possible. Maybe review
> > your RAM configuration too, ensure that the sticks are on the same
> > supported refresh rate and distributed across the slots in an approved
> > way.
> 
> There is only one RAM stick (of 16 GB), so there should be no problems
> of that kind.
> 
> I'm afraid I won't find an explanation of that file system corruption :-(
> 
> Thanks to Franco and Nicholas for your responses,
> Jesper

Re: Filsystemkorruption i ext4?

[Jesper Dybdal]

[Sorry - I accidentally sent this too quickly in an incomplete state.  
Second try here:]


On Wed, Mar 20, 2024, 11:28 AM Jesper Dybdal 
 wrote:



I think I'll let memtest86+ run overnight one of the coming nights.

Unless it is simply a RAM error, then it is a bit scary...



I've now let memtest86+ run for 9 hours, during which it did 14 passes 
of all its tests.  It found nothing wrong.


On 2024-03-20 22:58, Nicholas Geovanis wrote:
I have seen that a couple times, unlikely but possible. Maybe review 
your RAM configuration too, ensure that the sticks are on the same 
supported refresh rate and distributed across the slots in an approved 
way.


There is only one RAM stick (of 16 GB), so there should be no problems 
of that kind.


I'm afraid I won't find an explanation of that file system corruption :-(

Thanks to Franco and Nicholas for your responses,
Jesper

--
Jesper Dybdal
https://www.dybdal.dk

Re: Filsystemkorruption i ext4?

[Jesper Dybdal]

On 2024-03-20 22:58, Nicholas Geovanis wrote:


On Wed, Mar 20, 2024, 11:28 AM Jesper Dybdal 
 wrote:


I have now done the following:
* Checked the RAID array - no problems found.
* Run fsck.  It found three cases of the block count being
incorrect.  I
don't know which the other two affected files are.
* Run one pass of memtest86+.  Nothing found.

So it seems not to be a problem with the disks.
A bug in ext4?  Well, ext4 has always done its job for me wihtout
problems.
A RAM error that memtest86+ did not find?  Possible.  Once upon a
time,
when you bought an ordinary pc, its RAM had ECC as a matter of
course;
unfortunately, that is not the case nowadays.

I think I'll let memtest86+ run overnight one of the coming nights.

Unless it is simply a RAM error, then it is a bit scary...


I've now let memtest86+ run for 8 hours, during which i did 14 passes of 
all its tests.  It found nothing wrong.
I have seen that a couple times, unlikely but possible. Maybe review 
your RAM configuration too, ensure that the sticks are on the same 
supported refresh rate and distributed across the slots in an approved 
way.


Regards,
Jesper

On 2024-03-19 21:47, Franco Martelli wrote:
> On 19/03/24 at 15:43, Jesper Dybdal wrote:
>
>>
>> My plan is to boot a rescue disk and mount that partition
read-only.
>> Then:
>> * If the file looks ok after reboot, then I'll strongly suspect
the
>> RAM - and run memtest.
>> * Otherwise, I'll have to run fsck and see what happens.
>>
>> kernel version:
>> root@nuser:~# uname -a
>> Linux nuser 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31)
>> x86_64 GNU/Linux
>>
>> The partition in question is a RAID 1 controlled by md.
>
> Another check you can perform it is on the RAID array, by
default it
> runs on the first Sunday of each month at 00:57. You should have
this
> file /etc/cron.d/mdadm that takes care to run this check monthly.
>
> Before you reboot, does it look OK /proc/mdstat ?
>

-- 
Jesper Dybdal

https://www.dybdal.dk





--
Jesper Dybdal
https://www.dybdal.dk

Re: making Debian secure by default

[Andy Smith]

On Thu, Mar 28, 2024 at 12:28:56AM -0400, Lee wrote:
> On Wed, Mar 27, 2024 at 10:07 PM Andy Smith wrote:
> >
> > Hi,
> >
> > On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> > > I just saw this advisory
> > >   Escape sequence injection in util-linux wall (CVE-2024-28085)
> > > https://seclists.org/fulldisclosure/2024/Mar/35
> > > where they're talking about grabbing other users sudo password.
> >
> > It doesn't work by default on Debian as it relies on
> > command-not-found automatically running on the user's input.
> > command-not-found can be installed, however…
> >
> > > oof.  Are there instructions somewhere on how to make Debian secure by 
> > > default?
> >
> > Between the fact that "secure" means different things to different
> > people and that this advisory was only released a few hours ago, I
> > don't think you can reasonably expect documentation to already be
> > published for your standard of "secure".
> 
> You snipped the bit from the man page about users becoming more more
> conscious of various security risks & removing write access by
> default.

It's just an opinion by the author of the man page.

I'm just not sure that you'll find any "hardening" guide that will
specifically say "disable writing to your terminal as there might be
a bug in a binary that is setgid tty" before yesterday's reveal that
there is such a bug in "wall".

The more general advice to audit every setuid/setgid binary is more
likely to be present.

> Considering how long it takes something to migrate into stable I'm
> guessing that man page is pretty old.  So I don't think it's
> unreasonable to expect some kind of secure by default installation
> option.

I wouldn't be surprised if the man page is 10 years old. Linux
distributions do not tend to be that internally consistent. Lots of
weird things get put into man pages by their authors and
distributions don't always feel obliged to obey all of them;
sometimes they are even conflicting between each other.

Things are more coherent in BSD land, where the base system is
developed alongside the kernel, by the same people.

I do agree with you though that "mesg n" would be a much better
default and it's a shame we worked that out by seeing a ten year old
bug revealed.

It might be worth submitting a wishlist bug to Debian. I'm not
entirely sure of which package but I suppose "util-linux" would make
sense since that's where "mesg" comes from. It could ask for a shell
snippet in profile.d to set the default to "n" in the name of
security, and reference this CVE.

If the maintainer of util-linux doesn't agree, then the next thing
I'd try is a bug against the Debian Administrator's Handbook:

https://www.debian.org/doc/manuals/debian-handbook/

This has a chapter on security, so possibly it would be appropriate
to mention "m,esg n" there.

> > As you've never heard of "mesg" and probably don't use "wall" I
> > doubt you will have any issues chmod 0 /usr/bin/wall and then
> > setting it immutable¹ with chattr +i.
> 
> I suppose that's one way.  I'd rather uninstall it.

Problem is it's part of "bsdutils" so that would uninstall the whole
package and all its other tools.

A divert (man dpkg-divert) ciuld be used to remove the binary, but I
prefer chmod 0 and immutable as a less drastic approach.

There is also the issue that the user's terminal remains writeable by
processes in "tty" group - all that's been achieved is to stop one
program that has a known bug from doing so. There could be others,
and we've established that most users probably do not want or need
other users to write to their terminals. So "mesg n" is still a good
idea.

Thanks,
]Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

VMs Windows, qual virtualizador é melhor?

[hamacker]

Olá Pessoal,

Antes quando era php, eu usava apenas meu notebook com linux puro sangue,
Daí tive que trocar de trabalho, e daí fui linux em servidores, mas também
programo e nesta empresa é Delphi e por causa disso, meu desktop é um
Windows.
Mas recentemente, consegui autorização para usar Linux no meu desktop e
apenas por causa do Delphi e coisas do MSSQL Server, vou precisar usar uma
VM Windows.
Eu usei muito bem o virtualbox no passado quando precisei do Windows no meu
notebook, mas como já faz tempo que não virtualizo nada no meu desktop,
gostaria de saber de vocês se o VirtualBox ainda é o melhor para
virtualizar Windows.

[] ´s

[SOLVED] Re: variables in bash

[Hans]

Hi, 

thank you all for the fast response. It helped a lot and made everything 
clear.

The problem is solved.

Have a nice eastern.

Best

Hans

Re: making Debian secure by default

[Emanuel Berg]

Michael Kjörling wrote:

>> "Secure by default" is an OpenBSD slogan BTW. Or they have
>> made it into one at least. But I'm not sure it is any more
>> secure than Debian - maybe.
>> 
>>   https://www.openbsd.org/security.html
>
> If I'm not mistaken, OpenBSD is "secure by default" by being
> "extremely minimalistic by default".
>
> Last I looked, which in fairness was a while ago, a default
> installation of OpenBSD includes almost nothing that normal,
> present-day users would expect to find on their system. [...]

Ah, surely it can't refer to that as that would be completely
ridiculous as it would imply "wanna install stuff? sure, but
then it isn't secure anymore".

-- 
underground experts united
https://dataswamp.org/~incal

Re: variables in bash

[Paul M Foster]

On Thu, Mar 28, 2024 at 10:37:25AM +0100, Hans wrote:

> Hi folks,
> 
> just an easy question:
> 
> What is the difference (if any) between the following two variables in a 
> shellfile in bash:
> 
> 1. mypath=/home/user1/Tools/

Here you are assigning a value to the variable "mypath". You can surround
"/home/user1/Tools" with quotes if you like, but it is not strictly
necessary.

> 
> and $mypath

Here you are actually *using* the variable "mypath".

Here is another example:

NAME="paulf"
echo "My name is $NAME."

which will yield:

My name is paulf.


-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: variables in bash

[Greg Wooledge]

On Thu, Mar 28, 2024 at 10:37:25AM +0100, Hans wrote:
> What is the difference (if any) between the following two variables in a 
> shellfile in bash:
> 
> 1. mypath=/home/user1/Tools/
> 2. mypath="/home/user1/Tools/"

They are the same.  The quotes are optional here, because your assignment
doesn't contain any whitespace.

The quotes would be required if you had something like:

mypath="/mnt/c/Program Files/"

In any case, the assignment is the easy part.  Most people get this
part right.  Where they screw up is here:

> and $mypath

Whenever[1] you use "$mypath", you'll want double quotes around it.
Otherwise, it'll get split into multiple words at whitespace, and
will also be subject to filename expansion.  You don't want that.

mypath="/mnt/c/Program Files/"
if ! test -d $mypath; then ...  # wrong

The example above will *not* work, because the space in the middle
of $mypath's value will cause the test command to receive two
separate words, instead of one word.  It needs to be quoted:

mypath="/mnt/c/Program Files/"
if ! test -d "$mypath"; then ...# right

> Is this in bash the same? Do other shells (sh, zsh, whatever) handle these 
> two 
> different?

Most quoting rules are the same in all sh-derived shells, including the
rules I talked about here.

As you dive deeper into shell scripting, you'll find some cases where
the rules change a bit across different shells, but so far you're still
in the shallow end.

[1] There are some exceptions, but for now, go with the simplest rule:
"When in doubt, double-quote it."

Re: making Debian secure by default

[Michael Kjörling]

On 28 Mar 2024 06:16 +0100, from in...@dataswamp.org (Emanuel Berg):
> "Secure by default" is an OpenBSD slogan BTW. Or they have
> made it into one at least. But I'm not sure it is any more
> secure than Debian - maybe.
> 
>   https://www.openbsd.org/security.html

If I'm not mistaken, OpenBSD is "secure by default" by being
"extremely minimalistic by default".

Last I looked, which in fairness was a while ago, a default
installation of OpenBSD includes almost nothing that normal,
present-day users would expect to find on their system. Once you go
beyond the default installation by adding useful packages, you also go
beyond at least a large part of the "secure by default" promise.

And similarly that most network-enabled software installs by default
with all network-related functionality turned off or heavily
restricted, so the first thing you have to do after installing
something is to turn on the functionality for which you installed it.
But up until the point that you do that, the software you installed
very likely is secure (because it's reachable at most by people you
already trust at least to some degree).

Which doesn't mean that Debian can't be "more secure by default" by
installing services in a turned-off and locked-down manner and
expecting the administrator to open them up and do so in a secure
manner. But I rather suspect that most people who do install a package
do so because they want to use it; so a reasonably secure but still
useful setup out of the package manager would seem more practically
useful to most people.

Security and usability are often (but not always) at odds with each
other. The most secure system possible generally won't be very usable.

And for a real-world use case for wall, I have apcupsd set up to send
notifications to everywhere if there's a power failure, and ahead of a
power-failure system shutdown. Doesn't make much difference if I am at
the console, but is very useful if I'm logged in remotely.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: making Debian secure by default

[Marc SCHAEFER]

Hello,

On Wed, Mar 27, 2024 at 05:30:50PM -0400, Lee wrote:
> Apparently the root of the security issue is that wall is a setguid program?

a) wall must be able to write to your tty, which is not possible
   if wall is not installed setguid OR if people have sane permissions
   on their terminals (e.g. set to mesg n)

b) in addition, for this exploit to run, command-not-found must be
   started with the not found command as argument: in the two Debian
   releases I just tried (buster and bookworm), with bash,
   command-not-found was not installed.

The idea of the exploit is that you get a prompt for entering a sudo
password, which is a simple text (which gets more convincing because
of a recently introduced bug in wall which does not filter out terminal
escape / control sequences), then you type the root password, which
is presumably not the name of an existing command, so command-not-found
PASSWORD is run, and someone on another terminal and user can do
a ps to see that password argument if he is quick or polling.

To fix this:

a) don't type a root password / sudo password unless you know that
   it should happen

b) don't allow others to write on your terminals, in particular
   if you run priviledged commands and expect sudo prompts

c) patch wall so that its texts are always shown to be
   different from other program outputs (== filter out
   anything else than printable characters)

   THIS IS MY PREFERRED WORKAROUND :)
   (mixing controls (prompts) and data is always
a very bad idea)

d) don't have other users on your machine / use containers.

> So.  There is a program called 'mesg',  hrmmm..

30 years ago it was common practice to use wall (to signal stuff to
users, e.g. used by shutdown(8)).

> oof.  Are there instructions somewhere on how to make Debian secure by 
> default?

Looks like it is, by not installing command-not-found by default
(apparently Ubuntu does).  Presumably by chance.

Re: Debian 11 PHP 7.4 – Mysql 8 - Can’t get Mysqli_connect to work

[Greg Wooledge]

On Thu, Mar 28, 2024 at 10:36:01AM +0100, Bernard wrote:
> But I've found more problems, concerning $_REQUEST, $_GET...
> 
> The old way that I used 11 yrs ago no longer works :
> 
> $nom = S_GET [‘nom’] ;
> 
> no longer operates with php 7.4. This code is simply ignored. S_REQUEST,
> $_POST do not work either.

You mentioned $_GET and then you wrote S_GET.

You also have Unicode curly quote marks there, not ASCII apostrophes.

It's impossible for us to tell whether your PHP code is actually broken,
or whether you *retyped* it with errors for your email.

variables in bash

[Hans]

Hi folks,

just an easy question:

What is the difference (if any) between the following two variables in a 
shellfile in bash:

1. mypath=/home/user1/Tools/

and $mypath

or
2. mypath="/home/user1/Tools/"

and $mypath

Is this in bash the same? Do other shells (sh, zsh, whatever) handle these two 
different?

Thanks for any answer, can be short!

Best regards

Hans


  

Re: Debian 11 PHP 7.4 – Mysql 8 - Can’t get Mysqli_connect to work

[Bernard]

Yes, this list (exactly the same here) shows that mysqli.so is loaded. 
In any case, as said before, this function does operate as I have checked.


But I've found more problems, concerning $_REQUEST, $_GET...

The old way that I used 11 yrs ago no longer works :

$nom = S_GET [‘nom’] ;

no longer operates with php 7.4. This code is simply ignored. S_REQUEST, 
$_POST do not work either.


Could someone show me how I should write these few lines dating 2010… 
(worked at least till 2013), which code is now ignored by php 7.4 with 
no explanations since I don’t have debugging function active. This 
example code comes from Kevin Yanks' s book dating 2010 :




These lines are now ignored by php 7.4

In any case, I’ve checked my php.ini (which I sent here a few days ago), 
and it seems to say that cookies are activated as well as $_REQUEST and 
other concerned functions.


On 26/03/2024 10:38, Bernard wrote:

ls -Al /usr/lib/php/20190902

Re: Installation de VirtualBox par les dépots Debian?

[Lucas Nussbaum]

On 28/03/24 at 03:57 +0100, hamster wrote:
> Le 27/03/2024 à 10:29, Alex PADOLY a écrit :
> > Bonsoir à tous,
> > 
> > 
> > Peut-on installer VirtualBox par les dépôts Debian, en effet
> > l'installation à partir du paquet Debian sur le site d'Oracle génère des
> > erreurs difficiles à résoudre.
> 
> Je suis pas sur d'avoir bien compris mais j'ai lu un truc du genre "la boite
> qui fait virtualbox a été rachetée par une boite pas du tout favorable aux
> valeurs du libre, virtualbox a cessé d'etre libre et donc a été virée des
> dépots débian".

VirtualBox est libre (les paquets sont dans Debian "contrib" pour
unstable, car ils dépendent d'un autre paquet non libre), mais Oracle
refuse de fournir des détails sur les problèmes de sécurité, ce qui rend
impossible une intégration dans Debian stable.

Voir https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466#215

A ma connaissance la situation n'a pas évolué depuis ce message.

Lucas

Re: Installation de VirtualBox par les dépots Debian?

[Lucas Nussbaum]

On 27/03/24 at 12:29 +0300, Alex PADOLY wrote:
> Bonsoir à tous,
> 
> Peut-on installer VirtualBox par les dépôts Debian, en effet l'installation
> à partir du paquet Debian sur le site d'Oracle génère des erreurs difficiles
> à résoudre.

Bonjour,

Des paquets pour VirtualBox sont disponibles dans fasttrack.debian.net
Voir
https://wiki.debian.org/VirtualBox#Debian_10_.22Buster.22.2C_Debian_11_.22Bullseye.22.2C_and_Debian_12_.22Bookworm.22

Lucas

Re: making Debian secure by default

[tomas]

On Thu, Mar 28, 2024 at 06:16:32AM +0100, Emanuel Berg wrote:
> "Secure by default" is an OpenBSD slogan BTW. Or they have
> made it into one at least. But I'm not sure it is any more
> secure than Debian - maybe.

That depends.

Cheers
-- 
t


signature.asc
Description: PGP signature