Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #268557 > unrolled thread

making Debian secure by default

Back to article view | Back to linux.debian.user

Contents

  making Debian secure by default Lee <ler762@gmail.com> - 2024-03-27 22:40 +0100
    Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 00:10 +0100
      Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 05:30 +0100
        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 14:40 +0100
          Re: making Debian secure by default Greg Wooledge <greg@wooledge.org> - 2024-03-28 16:30 +0100
            Re: making Debian secure by default Hans <hans.ullrich@loop.de> - 2024-03-28 16:50 +0100
              Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 19:20 +0100
                Re: making Debian secure by default Ralph Aichinger <ra@h5.or.at> - 2024-03-29 08:50 +0100
                Re: making Debian secure by default Stefan Monnier <monnier@iro.umontreal.ca> - 2024-03-29 20:10 +0100
                Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-03-29 20:40 +0100
            Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 17:00 +0100
              Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 21:20 +0100
            Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-28 18:50 +0100
              Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 20:40 +0100
              Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-29 18:00 +0100
                Re: making Debian secure by default Joe <joe@jretrading.com> - 2024-03-29 18:30 +0100
                  Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-29 18:50 +0100
                  Re: making Debian secure by default Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-04-01 02:30 +0200
                    Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-04-01 03:50 +0200
                      Re: making Debian secure by default Roberto C. Sánchez <roberto@debian.org> - 2024-04-01 05:00 +0200
                      Re: making Debian secure by default Nate Bargmann <n0nb@n0nb.us> - 2024-04-01 10:40 +0200
                        Re: making Debian secure by default <tomas@tuxteam.de> - 2024-04-06 09:50 +0200
                          Re: making Debian secure by default Nate Bargmann <n0nb@n0nb.us> - 2024-04-06 09:50 +0200
                            Re: making Debian secure by default <tomas@tuxteam.de> - 2024-04-06 09:51 +0200
                        Re: making Debian secure by default <tomas@tuxteam.de> - 2024-04-06 09:50 +0200
                        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-04-06 09:50 +0200
                        Re: making Debian secure by default Nate Bargmann <n0nb@n0nb.us> - 2024-04-06 09:51 +0200
                        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-04-06 09:51 +0200
                          Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-04-06 09:51 +0200
                          Re: making Debian secure by default Nate Bargmann <n0nb@n0nb.us> - 2024-04-06 09:52 +0200
                          Re: making Debian secure by default Charles Curley <charlescurley@charlescurley.com> - 2024-04-06 09:52 +0200
                        Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-04-06 09:51 +0200
                      Re: making Debian secure by default John Hasler <john@sugarbit.com> - 2024-04-06 09:51 +0200
                        Re: making Debian secure by default Joe <joe@jretrading.com> - 2024-04-06 09:52 +0200
                          Re: making Debian secure by default John Hasler <john@sugarbit.com> - 2024-04-06 09:52 +0200
                      Re: making Debian secure by default Joe <joe@jretrading.com> - 2024-04-06 09:52 +0200
                Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-29 18:50 +0100
                  Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-29 21:00 +0100
                    Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-30 17:10 +0100
            Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 19:10 +0100
              Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-03-28 23:20 +0100
      Re: making Debian secure by default Florent Rougon <f.rougon@free.fr> - 2024-03-28 17:30 +0100
        Re: making Debian secure by default Florent Rougon <f.rougon@free.fr> - 2024-03-28 18:10 +0100
        Re: making Debian secure by default Greg Wooledge <greg@wooledge.org> - 2024-03-28 18:10 +0100
          Re: making Debian secure by default Florent Rougon <f.rougon@free.fr> - 2024-03-28 18:10 +0100
    Re: making Debian secure by default jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-28 00:40 +0100
      Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 00:50 +0100
        Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 05:50 +0100
    Re: making Debian secure by default <tomas@tuxteam.de> - 2024-03-28 06:20 +0100
      Re: making Debian secure by default Emanuel Berg <incal@dataswamp.org> - 2024-03-28 06:30 +0100
        Re: making Debian secure by default <tomas@tuxteam.de> - 2024-03-28 08:20 +0100
        Re: making Debian secure by default Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-28 12:20 +0100
          Re: making Debian secure by default Emanuel Berg <incal@dataswamp.org> - 2024-03-28 12:40 +0100
            Re: making Debian secure by default David Wright <deblis@lionunicorn.co.uk> - 2024-03-28 21:40 +0100
              Re: making Debian secure by default Emanuel Berg <incal@dataswamp.org> - 2024-03-29 10:40 +0100
                Re: making Debian secure by default David Wright <deblis@lionunicorn.co.uk> - 2024-03-30 04:00 +0100
      Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-28 15:50 +0100
      Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 17:30 +0100
        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 18:10 +0100
          Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 21:50 +0100
        Re: making Debian secure by default tomas@tuxteam.de - 2024-03-28 18:30 +0100
          Re: making Debian secure by default Lee <ler762@gmail.com> - 2024-03-28 20:30 +0100
            Re: making Debian secure by default Greg Wooledge <greg@wooledge.org> - 2024-03-28 20:30 +0100
              Re: making Debian secure by default Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-28 21:50 +0100
            Re: making Debian secure by default tomas@tuxteam.de - 2024-03-28 21:20 +0100
              Re: making Debian secure by default Curt <curty@free.fr> - 2024-03-29 17:10 +0100
                Re: making Debian secure by default debian-user@howorth.org.uk - 2024-03-29 21:50 +0100
      Re: making Debian secure by default debian-user@howorth.org.uk - 2024-03-28 22:50 +0100
    Re: making Debian secure by default Marc SCHAEFER <schaefer@alphanet.ch> - 2024-03-28 12:10 +0100
      Re: making Debian secure by default Franco Martelli <martellif67@gmail.com> - 2024-03-28 17:30 +0100
      Re: making Debian secure by default Michel Verdier <mv524@free.fr> - 2024-03-28 17:30 +0100
        Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-28 17:40 +0100
    Re: making Debian secure by default Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-28 21:50 +0100
    Re: making Debian secure by default Richmond <dnomhcir@gmx.com> - 2024-03-28 21:50 +0100
    Re: making Debian secure by default Jeffrey Walton <noloader@gmail.com> - 2024-03-29 16:40 +0100
    Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-31 21:10 +0200
      Re: making Debian secure by default Roberto C. Sánchez <roberto@debian.org> - 2024-03-31 21:30 +0200
        Re: making Debian secure by default gene heskett <gheskett@shentel.net> - 2024-03-31 22:30 +0200
          Re: making Debian secure by default Andy Smith <andy@strugglers.net> - 2024-03-31 23:20 +0200
            Re: making Debian secure by default gene heskett <gheskett@shentel.net> - 2024-04-01 01:00 +0200

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#268610

On Thu, Mar 28, 2024 at 5:07 PM Lee <ler762@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#268587

Hi,

Le 27/03/2024, Andy Smith <andy@strugglers.net> 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):

ahhhh

------------------------------------------------------------------------

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

Thanks, regards

-- 
Florent

[toc] | [prev] | [next] | [standalone]

#268592

Le 28/03/2024, Florent Rougon <f.rougon@free.fr> 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

[toc] | [prev] | [next] | [standalone]

#268593

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.

[toc] | [prev] | [next] | [standalone]

#268594

Le 28/03/2024, Greg Wooledge <greg@wooledge.org> 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

[toc] | [prev] | [next] | [standalone]

#268560

On 28/3/24 05:30, Lee wrote:
> oof.  Are there instructions somewhere on how to make Debian secure by default?


Further down the advisory is

"

   Some distros, like Debian, do not seem to have a command like
   command-not-found by default. There does not seem to be a way to
   leak a users password in this case then, even though we can send
   escape sequences to them.

"

Which implies that Debian is secure by default against this particular 
exploit

[toc] | [prev] | [next] | [standalone]

#268561

Hello,

On Thu, Mar 28, 2024 at 07:37:13AM +0800, jeremy ardley wrote:
>   Some distros, like Debian, do not seem to have a command like
>   command-not-found by default.

[…]

> Which implies that Debian is secure by default against this particular
> exploit

I suspect if OP is worried about users potentially falling for a
fake sudo password prompt then OP is probably not happy about all
the other possibilities around putting arbitrary text on a user's
terminal.

Also as mentioned, command-not-found is packaged in Debian…

Getting rid of the "wall" command seems reasonable for most people.
It's been almost 30 years since I used it for anything useful.

Thanks,
Andy

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

[toc] | [prev] | [next] | [standalone]

#268563

On Wed, Mar 27, 2024 at 10:22 PM Andy Smith wrote:
>
> Hello,
>
> On Thu, Mar 28, 2024 at 07:37:13AM +0800, jeremy ardley wrote:
> >   Some distros, like Debian, do not seem to have a command like
> >   command-not-found by default.
>
> […]
>
> > Which implies that Debian is secure by default against this particular
> > exploit
>
> I suspect if OP is worried about users potentially falling for a
> fake sudo password prompt then OP is probably not happy about all
> the other possibilities around putting arbitrary text on a user's
> terminal.

Yes, that.

I'm not thrilled with the idea of anybody putting arbitrary text on
someone else's terminal; what really concerns me is the ability to
send control codes.  Wasn't there some exploit that involved injecting
text and a control code that acted like a carriage return?

Lee

[toc] | [prev] | [next] | [standalone]

#268564

[Multipart message — attachments visible in raw view] — view raw

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. Randomly
reaching into the CVE box will most probably keep you from actually
working on your real issues. E.g. your browser. Or your social media
account.

Cheers

[1] https://xkcd.com/1200/
-- 
t

[toc] | [prev] | [next] | [standalone]

#268565

"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

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

[toc] | [prev] | [next] | [standalone]

#268566

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#268571

On 28 Mar 2024 06:16 +0100, from incal@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?”

[toc] | [prev] | [next] | [standalone]

#268574

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

[toc] | [prev] | [next] | [standalone]

#268604

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.

[toc] | [prev] | [next] | [standalone]

#268612

David Wright wrote:

>> 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. [...]

It means as soon as you start doing stuff with the software,
it isn't secure anymore. Which is comical to some extent as
doing stuff is the purpose of computers.

So to base security boasting on people having the most
minimal, restricted and inactive system, it is like boasting
this marvelous piece of body armor is guaranteed to not have
a single infantryman killed - just don't go to war.

(Note that now I'm just making fun at the slogan and boasting,
not saying anything negative of their OS necessarily - I've
used it myself, it send pretty good and, indeed, secure.)

>  "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).

The more you install, the less secure it gets. Yeah, can't
base the security model on that.

They should do it the other way around, write a piece of
software that breaks everything. Install in on OpenBSD and if
it breakes it, OpenBSD is not more secure than anyone else.
If nothing happens tho most likekly you are safe.

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

[toc] | [prev] | [next] | [standalone]

#268636

On Fri 29 Mar 2024 at 10:31:09 (+0100), Emanuel Berg wrote:
> David Wright wrote:
> 
> >> 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. [...]
> 
> It means as soon as you start doing stuff with the software,
> it isn't secure anymore.

As you wrote. But software isn't just "secure" or "not secure",
all or nothing. Security, in any aspect of life, is gradational.

> Which is comical to some extent as
> doing stuff is the purpose of computers.
> 
> So to base security boasting on people having the most
> minimal, restricted and inactive system, it is like boasting
> this marvelous piece of body armor is guaranteed to not have
> a single infantryman killed - just don't go to war.

You don't expect people working at HQ to get shot or blown up,
but that is a more likely fate for those fighting at the front.
As well as variations with seniority and physical position,
there will be temporal variations, just like in civilian life,
1 through 5 or green through red etc.

> (Note that now I'm just making fun at the slogan and boasting,
> not saying anything negative of their OS necessarily - I've
> used it myself, it send pretty good and, indeed, secure.)
> 
> >  "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).
> 
> The more you install, the less secure it gets. Yeah, can't
> base the security model on that.

Not a base; it's just inevitable, both in software and life.
You're increasing your attack surface as you install and use
more software, just like driving, visiting bars, attending
concerts, or going on foreign or adventure holidays.

> They should do it the other way around, write a piece of
> software that breaks everything. Install in on OpenBSD and if
> it breakes it, OpenBSD is not more secure than anyone else.
> If nothing happens tho most likekly you are safe.

I don't know about OpenBSD specifically, but in general it's
already done, by such methods as exposing software to malicious
and random inputs, corner cases, and so on. That doesn't have
to mean it's done /instead of/ auditing.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#268580

On 2024-03-28, <tomas@tuxteam.de> <tomas@tuxteam.de> 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.

[toc] | [prev] | [next] | [standalone]

#268588

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 / <something to show files with
uid or gid perms> 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

[toc] | [prev] | [next] | [standalone]

#268591

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 / <something to show
> 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

[toc] | [prev] | [next] | [standalone]

#268608

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 / <something to show
> > 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

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web