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.debi
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 s
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 agains
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
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 ev
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.
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.htm
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,
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 exter
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
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.
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' inst
> 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 t
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
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.
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 def
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 sugg
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 defaul
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)
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 ro
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
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 peopl
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 mes
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 oth
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 mes
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" ther
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
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
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 "wa
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 (
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 conv
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 resid
[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 le
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 oth
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://s
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
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
> "extr
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 surr
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'
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
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
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
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
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
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
45 matches
Mail list logo
