hi,
I also should have thrown in some more URLs, namely:
https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/debian-edu-bookworm-manual.html
https://jenkins.debian.net/userContent/debian-edu-doc/debian-edu-doc-en/debian-edu-bookworm-manual.pdf
https://jenkins.debian.net
There is some good discussion here. I have some comments for those
interested:
First, many thanks to Javier for building the *Securing Debian Manual*.
That was a massive undertaking, and it is well-written and organized. I
used it frequently between 2015 and 2017, and it helped me better secure
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
You can cut all the flowers, but you can’t keep spring from coming.
#transdayofremembrance #berlin (2024)
signature.asc
Description: PGP signature
ue I ran into wasn't missing
content (though I didn't read the whole thing), but it didn't take long before
I found information that was outdated and no longer applicable to modern Debian
releases. However, it does appear some of those files have been modified in the
past year,
ly convinced that the current format is a barrier to
contributors as the Debian website uses WML and this has not hindered
contributions. When I've received snippets of text (even if unformatted
form) I have gladly included them in the manual. The XML files available in
Sala (
https://salsa.debia
On Tue, Jun 10, 2025 at 09:57:43PM +0200, Javier Fernandez-Sanguino wrote:
>Moving the manual to a Wiki could be an option but I would rather first
>have an updated version/content using the current package/toolset and then
>consider moving it to a wiki.
The current format is arcane an
h "hands" working on it
Those thoughts aside I would be glad to help in pushing patches / new
versions of the manual to the archive if people start actively contributing
to it.
Best regards,
Javier
El mar, 10 jun 2025, 15:11, Dave P. escribió:
> Excellent idea Noah, especially Debi
Excellent idea Noah, especially Debian *server* security. I'm willing to
help. The Wiki option sounds like the best way to me.
Some points:
- SSH server security
- Firewalls: I think someone mentioned nftables, and that is optimal. But
for people choosing between UFW and firewalld front-end
I certainly think having an up to date "Securing Debian" document is a worthy
endeavor, especially for server management. I've been using Debian to host my
family home server for years now and have learned a lot in that time, so I
actually started my own take on a re-write a wh
te for everyone)
and execute it. Alas Debian by default relies on /var/lib/dpkg/ being
executable for various pre/post-inst/rm scripts, and recently libc update
required even /tmp to be executable. What a pity that at least /tmp cannot be
noexec.
Also a section about web hosting privilegies mi
Hi Noah,
> Most basically, I wonder if folks think this is a worthy idea.
Another long-term Debian user here who normally doesn't post to this
list. I am very much in favour of this idea. There is a lot of
information out there on this topic, but a lot of nonsense and flame
wa
I'd like to see updates on Active Response.
I've adopted Wazuh for such a task.
On 6/9/25 09:20, Noah Meyerhans wrote:
Hi all. The Securing Debian Manual (the harden-doc package) is
woefully out of date and doesn't provide accurate guidance for
operating modern software in the
7;t believe
> that it's feasible to provide useful advice for a meaningful subset of
> Debian packages.
sounds sound! I also liked your mock/draft table of contents!
> Should we maybe consider maintaining this document on wiki.debian.org,
> rather than being a centrally maintained do
I am usually radio silent on this list but this project is interesting to
me because I have 11 years of experience doing forensics in a purely Debian
environment. I am not a full stack developer, I can script in bash and
python but this is not enough to contribute to code. Contributing to this
Hi all. The Securing Debian Manual (the harden-doc package) is
woefully out of date and doesn't provide accurate guidance for
operating modern software in the current threat landscape. I'd like
to begin the task of updating it to reflect current best practice and
to document current
t; the CVE has no Debian bug ID.
As an example, let's consider CVE-2025-4516 affecting the python package.
https://security-tracker.debian.org/tracker/CVE-2025-4516
In the CVE:
Upstream has already released patches for the main branch and version 3.14.
However, this CVE currently has no
Hi
Let's comment on some of your specific CVEs, thanks for reaching out.
On Mon, May 12, 2025 at 06:09:37AM +, Fu, Rong (CN) wrote:
> Dear maintainer,
>
>
>
> I would like to clarify the appropriate circumstances under which a
> Debian bug report should be submitte
Hello Chris,
Thank you for your reply.
Am 13.05.2025 12:39 schrieb Chris Boot:
I don't think that your software _should_ offer cipher
selection options
[..]
If your users know enough about ciphers to make their own judgements
about them and make their own selections, they should also know about
On 13/05/2025 10:35, c.bu...@posteo.jp wrote:
[...]
I know nearly nothing about Ciphers and stuff like this.
I would like to give my users some hands-on about the available and used
ciphers. I would like to warn if they use an out-dated one and I want to
recommend some.
[...]
I also know lit
like to warn if they use an out-dated one and I
want to recommend some.
But to do this I need a strong, official and trustful reference. Does
Debian has something like his?
I was able to find a list of recommendations from the BSI (a German
institution) but without a list of out-dated Ciphers.
reference. Does
Debian has something like his?
I was able to find a list of recommendations from the BSI (a German
institution) but without a list of out-dated Ciphers.
Also the NIST has a document, but I am not able to understand it. I
couldn't find a list in it.
What do you think?
Rega
Dear maintainer,
I would like to clarify the appropriate circumstances under which a Debian bug
report should be submitted for CVE-related fixes.
Specifically, I'm uncertain about the following five scenarios:
Condition 1: The fix is already applied in sid, Trixie, but not yet in Boo
erested in collaborating with us when the
time comes to do this work?
Thanks,
Tanya
* * * * *
Tanya Brewer
she / her / hers
NVD Program Manager
Computer Security Division /ITL
NIST
-Original Message-
From: Booth, Harold (Fed)
Sent: Monday, December 2, 2024 8:09 AM
To: David A. Wheeler
arold
-Original Message-
From: David A. Wheeler
Sent: Sunday, December 1, 2024 3:30 PM
To: Booth, Harold (Fed) ;
debian-security@lists.debian.org
Cc: Wheeler, David A ; cpe_dictionary
; Kate Stewart ; Samir
Khakimov ; Holger Levsen
Subject: Re: Should Debian ask for a CPE when a CVE in Debian is
> On Feb 12, 2016, at 12:50 PM, Booth, Harold wrote:
>
> We welcome and encourage participation from any vendor to provide us with
> this information. We will be happy to work with Debian to accept their CPE
> submissions for products that they release. What would help you to
:
11/27/24 17:17 (GMT-05:00) To: debian-security@lists.debian.org,
cho...@binghamton.edu Subject: Re: I forgot my password and Debian need
password when booting
Can you get grub to appear? If you can an easy way to get in
Go to the end of the line with options and add to the end I think
To whom it may concern:
I'm not sure if this is appropriate for the "security" team, or if there is a
documentation team, but purely out of curiosity today I downloaded the
"Securing Debian" manual available in both the "harden-doc" package, an
Hello.
I know, buster is oldold ... But are there any plans to get a patched
release of libclamunrar9?
https://blog.clamav.net/2023/08/clamav-120-feature-version-and-111-102.html
Currently buster has only 0.102.3-0+deb10u1
Ist there any chance that the patched version (0.103.10) will be back-
port
>
> > > > It will not longer be possible to reliably derive the package name from
> > > > kernel release (see above), as both values are not really related
> > > > anymore.
> >
> > This package name seems to be missing the Debian release, which is
> > > kernel release (see above), as both values are not really related
> > > anymore.
>
> This package name seems to be missing the Debian release, which is
> mandatory to ensure that you can install 6.5.3-2 and 6.5.3-1 in
> parallel, which again is mandatory. That&#
ains more version info
> >
> > Example: linux-image-6.5.3-cloud-arm64
>
> > It will not longer be possible to reliably derive the package name from
> > kernel release (see above), as both values are not really related
> > anymore.
This package name seems to be missin
On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote:
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:
No, the first level is always: but the new kernel does not work.
The second is: I need to u
[ Removing some lists ]
On Sat, Oct 07, 2023 at 04:53:33PM +0200, Bastian Blank wrote:
> > ## Image packages contains more version info
> >
> > Example: linux-image-6.5.3-cloud-arm64
>
> > It will not longer be possible to reliably derive the package name from
> > kernel release (see above), as b
t two(?).
This means:
- Images and headers are always kept with the same versions.
- Different images (-arm64, -rt-arm64) are always kept together.
Counter proposal: Use see the kernel release as debian version and match
on the upstream version. But then we need to re-define what we put into
the
Hi
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.
We could encode that in the upstream version. Aka to have
co
without having to
track down old packages that may have been removed from the archive. This
feels like a normal and somewhat obvious Debian systems administration
thing to do to me.
I realize in the new signing regime every new kernel would have a separate
headers package (as opposed to today
> "Bastian" == Bastian Blank writes:
Bastian> The same as now: nowhere, because those packages have been
Bastian> removed from the archive already.
Bastian> And sadly you did not answer the question why a second
Bastian> degree error must not be worse then a worked around fir
as now: nowhere, because those packages have been removed from
the archive already.
And sadly you did not answer the question why a second degree error must
not be worse then a worked around first degree error?
> I know there is a lot of history behind the linux-headers package in
> debian. Howev
he way Debian does signing of
secure boot components. After the linux packages got built and accepted,
an automatic process takes the output and produces a new source package
that is uploaded, built and accepted. So the signed stuff will always
come later (between hours or days in normal cases, but e
On 03/10/2023 19.30, Bastian Blank wrote:
thread. Or freak out because meta packages remain uninstallable in
backports for days.
...
plus gcc or we change how backports works.
If uninstallable packages in backports are a problem, perhaps backports
needs something like britney to migrate pac
eaders matching this previously-used kernel
> that are required until we provide a kernel with the regression fixed?
>
I know there is a lot of history behind the linux-headers package in
debian. However since 5.2 there is a kernel config option, which
allows you to build the kernel headers as
On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
>...
> The core problem is that people assume they can get headers matching the
> currently running kernel, without upgrading first, see also the parallel
> thread.
>...
If the new kernel has a regression that affects the user, the use
e 03/10/2023 à 19:06, Bjørn Mork a écrit :
herve writes:
concerning the linux-headers. may i explain what happend to me.
I reinstalled a debian 11.6 some months ago. and last week i had to
make virtualbox functioning again. it had to "compile" some kernel
modules and need some &qu
Hi Sam
On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change. I have read multiple versions of this proposal, and your
> follow-ups, and I
herve writes:
> concerning the linux-headers. may i explain what happend to me.
>
> I reinstalled a debian 11.6 some months ago. and last week i had to
> make virtualbox functioning again. it had to "compile" some kernel
> modules and need some "headers". my ke
eader versions.
concerning the linux-headers. may i explain what happend to me.
I reinstalled a debian 11.6 some months ago. and last week i had to make
virtualbox functioning again. it had to "compile" some kernel modules
and need some "headers". my kernel (from the install
> "Bastian" == Bastian Blank writes:
Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
>> On 25/09/2023 00.50, Bastian Blank wrote:
>> > Already built modules remain until someone deletes it. So you
>> can also > switch back to the still installed old
On 2023-10-01, Bastian Blank wrote:
> So you upgrade the driver and libaries and suddenly your system fails
> until you reboot? Okay, I could imaging NVidia doing something like
> tying libraries to kernel modules. At least in the past they replaced
> gl libraries that did not longer work with X
Hi Michel
On Sun, Oct 01, 2023 at 12:19:22PM +0200, Michel Verdier wrote:
> On 2023-10-01, Bastian Blank wrote:
> > Ah, here lays the missconception. No, the 6.6 ones are not removed. Why
> > should they be? The system knows it can't rebuild them.
> As the old kernel driver is not rebuild it pe
On 2023-10-01, Bastian Blank wrote:
>> Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6
>> which is kept installed) and a new version of the gpu driver (which adds
>> support for 6.7). So the old gpu module for 6.6 gets removed and a new one
>> is built for 6.7 only (since
On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it. So you can also
> > switch back to the still installed older kernel version and it will have
> > the still working module availab
On Mon, Sep 25, 2023 at 02:03:35AM +0200, Bastian Blank wrote:
> The current way does not work. See all the bug reports about
> uninstallable packages and what not with dkms.
>
> To build modules against version x, you'll need to install version x of
> the headers, not x-1 or x+1. This currently
On Mon, 2023-09-25 at 04:35 +0200, Andreas Beckmann wrote:
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it. So you can
> > also
> > switch back to the still installed older kernel version and it will
> > have
> > the still working module availa
On 25/09/2023 00.50, Bastian Blank wrote:
Already built modules remain until someone deletes it. So you can also
switch back to the still installed older kernel version and it will have
the still working module available.
This is what I expect not to work.
Assume I have Linux 6.6 and a third-
Hi Ben
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatible on architectures
> support
Hi Andreas
On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> >
> > The modules will not longer be signed using the Secure Boot CA like the
> > EFI kernel image itself. Instead
On 24/09/2023 15.01, Bastian Blank wrote:
## Kernel modules will be signed with an ephemeral key
The modules will not longer be signed using the Secure Boot CA like the
EFI kernel image itself. Instead a key will be created during the build
and thrown away after.
Do I correctly assume that ch
On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
[...]
> ## Kernel modules will be signed with an ephemeral key
>
> The modules will not longer be signed using the Secure Boot CA like the
> EFI kernel image itself. Instead a key will be created during the build
> and thrown away after.
>
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
package: developers-reference
x-debbugs-cc: debian-security@lists.debian.org
hi,
On Tue, Jul 11, 2023 at 10:46:20PM +0200, Moritz Mühlenhoff wrote:
> > I found the Securing Debian Manual
> > (https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html).
> > This ve
Stephan Seitz writes:
> Hi!
>
> I found the Securing Debian Manual
> (https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html).
> This version is from 2017.
This document is in fact too outdated and not in a shape we should
prominently present it on the Debian
You won't find it there, and it doesn't matter. You only need to verify that
the signature is by the trusted key, which your output indicates that it was
(although you have to rely on a CA trust path).
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
I meant: Where to find *the date and time that the signature for the SHA512SUMS
file was produced* (on the website)?
--
> On 2023-06-23 20:59:07 +0200 (+0200), Julian Schreck wrote:
> > Where to find the former? (Or do I not need it for checking the
> > integrity of the download(s)?)
> [...]
> > >
On 2023-06-23 20:59:07 +0200 (+0200), Julian Schreck wrote:
> Where to find the former? (Or do I not need it for checking the
> integrity of the download(s)?)
[...]
> > > [1] : https://www.debian.org/CD/verify, e. g. 2011-01-05 [SC]
[...]
Please restate your question more precisely if this doesn't
Where to find the former? (Or do I not need it for checking the integrity of
the download(s)?)
--
> On Fri, 2023-06-23 at 16:53 +0200, Julian Schreck wrote:
> > I was downloading the netimage of bookworm, the signing key(s) and
> > sha sums when I noticed that my timestamp of the signature [0]
> >
ite not updated?
>
>Kind regards
>Julian
>--
>[0] :
>$ LC_ALL=C gpg --verify-files SHA512SUMS.sign
>gpg: assuming signed data in 'SHA512SUMS'
>gpg: Signature made Sat Jun 10 15:58:35 2023 CEST
>gpg:using RSA key DF9B9C49EAA9298432589D76DA87E80D6294B
On Fri, 2023-06-23 at 16:53 +0200, Julian Schreck wrote:
> I was downloading the netimage of bookworm, the signing key(s) and
> sha sums when I noticed that my timestamp of the signature [0]
> differs from the one on the website. [1]
> Is this a security issue or just a website not updated?
>
You
On Fri, Jun 23, 2023 at 12:40:19PM +0200, Stephan Seitz wrote:
> I found the Securing Debian Manual
> (https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html).
> This version is from 2017.
>
> It has „Chapter 6. Automatic hardening of Debian systems” which me
SHA512SUMS.sign
gpg: assuming signed data in 'SHA512SUMS'
gpg: Signature made Sat Jun 10 15:58:35 2023 CEST
gpg:using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Good signature from "Debian CD signing key "
[unknown]
gpg: WARNING: This key is not cert
Hi!
I found the Securing Debian Manual
(https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html).
This version is from 2017.
It has „Chapter 6. Automatic hardening of Debian systems” which mentions
Harden packages and Bastille. None of these packages exist anymore in
Hello everyone,
I'm Samson-W, the "Captain" of the harbian-audit project in the HardenedLinux
community.
The harbian-audit project is compliance implementation based on the STIG and
CIS.
Harbian-audit v0.7.0 is released, fix some bugs and add some new features. It
supports Debi
Hi
Our apache restarts fine. I'm on Debian 11.5 with unattended-upgrades for
bullseye-security ONLY
We have:
libssl1.1 Version: 1.1.1n-0+deb11u4) - updated 8 Feb 2023
and
apache2 Version: 2.4.54-1~deb11u1
So is this a Debian 11.6 problem ??
Cheers
Will
Will Salmon,
Sy
Le 24 janvier 2023 Carsten Schabacker a écrit :
> There is at least one open source alternative to 1password etc.
>
>
> https://psono.com/
But it don't operate ssh/gpg. Also it uses a clent/server architecture
much more complicated for personnal use. And keepassxc is a fork from
keepass and uses
Every account you have should have a unique, complex,
> password.
1password and lastpass are not opensource. keepassxc is GPL and packaged
in Debian. And it is pluggable in web browser and also ssh and gpg.
Cheers
;t forget to update the database, however).
You have to more, though. Spend some time on configuring your firewall
(in modern Debian that would be Firewalld (which configures netfilter).
Another thing is to enable the Debian security package repository and
regularly (anytime you start working, or crea
On 2023-01-22 at 20:30 +0300, Roman wrote:
> Hello. I'm a Windows 10 user. Unfortunately, I've used a lot of
> cracked programs in the past. I want to switch to debian and use only
> legal software. I want to write debian netinst to a flash drive. Is
> it possible that t
The only way to achieve 100% security is to totally disconnect the
computer, including any power connection. You are still vulnerable to
physical attacks, so for total security destroy all of the components.
--
Jonathan
Hello. I'm a Windows 10 user. Unfortunately, I've used a lot of cracked
programs in the past. I want to switch to debian and use only legal
software. I want to write debian netinst to a flash drive. Is it possible
that the distribution on the flash drive will be hacked through a Tro
-- Forwarded message -
От: Roman
Date: вс, 22 янв. 2023 г., 19:47
Subject: How to get 100% secure debian system?
To:
Hello. I'm a Windows 10 user. Unfortunately, I've used a lot of cracked
programs in the past. I want to switch to debian and use only legal
software.
Hi,
You may want to read this thread:
https://lists.debian.org/debian-security/2021/05/msg00010.html
https://lists.debian.org/debian-security/2021/05/msg00012.html
I'd suggest you also explain your context, you seem to use the Debian
tracker to trigger some action on your part, whil
Hello!
My name is Hadas, I'm in the Snyk Security Group. I've been in contact with
you a while back regarding the `no-dsa` field and its different tags.
I just want to further confirm if our understanding of the usage of the
various terms (`no-dsa`, `ignored`, `postponed`, "Minor issue") is corre
Am 16.05.22 um 11:38 schrieb Sylvain:
Hello,
Here's the result of debcheckroot on an entirely fresh install of
debian, without any access to the internet from a browser or a mail
client. I only:
- ran "apt update" to test my internet connection
- copied files on a USB st
private emails like this one as new to
debian-security. People will misinterpret your emails if they do not
know the whole conversation.
Elmar
P.S.: If emailing does not work for you, you can call me via phone,
usually on Tuesday, Wednesday and Thursday, but not this/next week; see
Hello,
Here's the result of debcheckroot on an entirely fresh install of
debian, without any access to the internet from a browser or a mail
client. I only:
- ran "apt update" to test my internet connection
- copied files on a USB stick
Here's the fileserror.lis:
..._..M
Hello,
Le 13/05/2022 à 20:30, Elmar Stellnberger a écrit :
From what Sylvain has answered me, she didn´t do that. As said the mail
header I got also did not show anything like that.
I must precise that I'm a man. "Sylvain" is for boys and "Sylvie" for
girls. :)
Sylvain
Sécherre. It means he is an NSA guy, since he had access to a
wiretapped
conversation.
https://lists.debian.org/debian-security/2022/05/msg00018.html
So far as I can see, the mail in question made it to debian-security
because it was posted to linux.debian.security and was then
automatically
On Fri, 2022-05-13 at 20:01 +0200, estel...@elstel.org wrote:
> Michael Lazin had published a private email between me an Sylvain
> Sécherre. It means he is an NSA guy, since he had access to a
> wiretapped
> conversation.
>
> https://lists.debian.org/debian-security/202
d access to a wiretapped
> > conversation.
> >
> > https://lists.debian.org/debian-security/2022/05/msg00018.html
> >
> > ---- Originalnachricht
> > Betreff: Re: Fwd: What is the best free HIDS for Debian
> > Datum: 12.05.2022 12:53
> > Von: Syl
conversation.
https://lists.debian.org/debian-security/2022/05/msg00018.html
Originalnachricht
Betreff: Re: Fwd: What is the best free HIDS for Debian
Datum: 12.05.2022 12:53
Von: Sylvain Sécherre
An: Elmar Stellnberger
Dear Elmar,
Don't worry about this, feel free to ci
Michael Lazin had published a private email between me an Sylvain
Sécherre. It means he is an NSA guy, since he had access to a wiretapped
conversation.
https://lists.debian.org/debian-security/2022/05/msg00018.html
Originalnachricht
Betreff: Re: Fwd: What is the best free
Dear Elmar,
Thank you for your tips. But before reinstalling from scratch on my
desktop, that is a lot of work, I will reinstall Debian on an old
netbook which is on a desk and I don't use anymore. I'll run debchekroot
on it and we will see...
I must apology if my English is not
Dear Vitaly
On 5/10/22 05:24, Vitaly Krasheninnikov wrote:
Hi Elmar,
Thank you for debcheckroot. I think it is a great project, which makes us one
step closer to a verifiable Debian system.
In this particular case, I'd like to point out the exact flags from fileserror.lis that you showe
On 10/05/2022 05:37, Vitaly Krasheninnikov wrote:
Thank you for debcheckroot. I think it is a great project, which makes us one
step closer to a verifiable Debian system.
In this particular case, I'd like to point out the exact flags from fileserror.lis that you showed
us: "..
Hi Elmar,
Thank you for debcheckroot. I think it is a great project, which makes us one
step closer to a verifiable Debian system.
In this particular case, I'd like to point out the exact flags from
fileserror.lis that you showed us: "..._.GM" and "..._..M".
According t
Am 09.05.22 um 13:34 schrieb t...@vandradlabs.com.au:
On 2022-05-09 18:04, Elmar Stellnberger wrote:
Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:
5. have we eliminated other causes of file mismatch - bad/incomplete
updates, corrupted HDD, bad RAM, user error ?
If exactly such files have
On 2022-05-09 18:04, Elmar Stellnberger wrote:
Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:
5. have we eliminated other causes of file mismatch - bad/incomplete
updates, corrupted HDD, bad RAM, user error ?
If exactly such files have been changed where there is reason to
manipulate them fo
This supports the use of rkhunter and running it once on first install but
you can manually find file changes systematically by becoming root and
going to the top level directory and running “find -ctime 1”, “find -ctime
-2” etc ad infinitum until you find all files that may have been
compromised.
Am 09.05.22 um 00:48 schrieb Tomasz Ciolek:
5. have we eliminated other causes of file mismatch - bad/incomplete
updates, corrupted HDD, bad RAM, user error ?
If exactly such files have been changed where there is reason to
manipulate them for a rootkit then one shall assume unequivocally th
Rkhunter does find patterns of known rootkits but it also finds indicators
like memory anomalies like I mentioned and it logs each file change from
the install, this is why ideally you should install it in a fresh system.
Thanks.
Michael Lazin
On Sun, May 8, 2022 at 3:45 PM wrote:
> Am 08.05.20
Am 08.05.2022 20:43, schrieb estel...@elstel.org:
P.S.: A memory only rootkit would still need a hook to reinstall on a
fresh boot.
Yes I know it is an issue. Debcheckroot does f.i. not check you
initrd. To fix this issue I would need to program an own piece of
software like debcheckinitrd.
1 - 100 of 3309 matches
Mail list logo
