Re: nft newbie

[Roger Price]

On Wed, 6 Jul 2022, Will Mengarini wrote:

* gene heskett  [22-07/06=We 18:50 -0400]:

The man page while quite voluminus is as
usual mostly bereft of useful examples.



has various examples.


May I continue this thread by asking more newbie questions?

I looked at the workstation example, but it doesn't even allow access via ssh. 
On my Debian 11 box I found /usr/share/doc/nftables/examples/workstation.nft 
which does show how to allow incoming ssh, http and https traffic.


Newbie 1: Is it normal for nftables configuration files to be executable?  As a 
newcomer, I expected something more "traditional", ie a file containing only key 
words and data values.


Newbie 2: Command ls -l /etc/nftables.conf reports

   -rwxr-xr-x 1 root root 228 Jan 17  2021 /etc/nftables.conf*

This looks as if anyone can read and execute this file.  I tried as a simple 
user and got the error message


   /etc/nftables.conf:3:1-14: Error: Could not process rule: Operation not 
permitted
   flush ruleset
   ^^

Is execution not permitted for non-root/non-file owner ?

Newbie 3: The configuration file begins with the Bash shebang #!/usr/sbin/nft -f 
but the Debian 11 man page for nftables says


  -f, --file filename Read input from filename. If filename is -, read from 
stdin.

and doesn't mention omitting the filename.  I'm guessing that -f with no file 
name means "read from the remainder of this file".  Is this correct?


My apologies for asking such trivial stuff.
Roger


 is an
HTML version of the man page, which is easier to navigate, at least.

 
may also be helpful.

Re: nft newbie

[Erwan David]

Le 07/07/2022 à 10:11, Roger Price a écrit :


I looked at the workstation example, but it doesn't even allow access 
via ssh. On my Debian 11 box I found 
/usr/share/doc/nftables/examples/workstation.nft which does show how to 
allow incoming ssh, http and https traffic.


Newbie 1: Is it normal for nftables configuration files to be 
executable?  As a newcomer, I expected something more "traditional", ie 
a file containing only key words and data values.


Yes it is. If you look at the first line you see it is a script to be 
evaluated by /usr/sbin/nft



Newbie 2: Command ls -l /etc/nftables.conf reports

    -rwxr-xr-x 1 root root 228 Jan 17  2021 /etc/nftables.conf*

This looks as if anyone can read and execute this file.  I tried as a 
simple user and got the error message


    /etc/nftables.conf:3:1-14: Error: Could not process rule: Operation 
not permitted

    flush ruleset
    ^^

Is execution not permitted for non-root/non-file owner ?


nft configuration is indeed possible only for root.

Newbie 3: The configuration file begins with the Bash shebang 
#!/usr/sbin/nft -f but the Debian 11 man page for nftables says


   -f, --file filename Read input from filename. If filename is -, read 
from stdin.


and doesn't mention omitting the filename.  I'm guessing that -f with no 
file name means "read from the remainder of this file".  Is this correct?


It's very old for me (I began unix in 1990)  but in my understanding 
when a file begins wth a shebang the line after the shebang is completed 
with the path to the file and the full line is then executed, thus 
You'll end with a command line of /usr/sbin/nft -f /etc/nftables.conf

Re: nft newbie

[Greg Wooledge]

On Thu, Jul 07, 2022 at 10:45:00AM +0200, Erwan David wrote:
> Le 07/07/2022 à 10:11, Roger Price a écrit :
> > Newbie 3: The configuration file begins with the Bash shebang
> > #!/usr/sbin/nft -f but the Debian 11 man page for nftables says
> > 
> >    -f, --file filename Read input from filename. If filename is -, read
> > from stdin.
> > 
> > and doesn't mention omitting the filename.  I'm guessing that -f with no
> > file name means "read from the remainder of this file".  Is this
> > correct?
> 
> It's very old for me (I began unix in 1990)  but in my understanding when a
> file begins wth a shebang the line after the shebang is completed with the
> path to the file and the full line is then executed, thus You'll end with a
> command line of /usr/sbin/nft -f /etc/nftables.conf

That's correct.  That's how shebangs work.

If you take a typical shell script, which begins with #!/bin/sh, and
you execute that, you'll end up with the kernel running a command such
as

  /bin/sh ./myscript

for you.  Likewise, a perl script will end up executing something like

  /usr/bin/perl /usr/bin/perlscript

and so on.  You are allowed to have one (1) argument word after the
interpreter name on a shebang line.  In the case of your nft script,
that option happens to be -f.  This will also be required for awk
scripts (with a shebang of #!/usr/bin/awk -f) and so on.

Re: Problem mounting encrypted blu-ray disc or image

[B.M.]

> > file "$IMGFILE"
> > LUKS encrypted file, ver 2 [, , sha256] UUID:
> > 835847ff-2cb3-4c6d-aa04-d3b79010a2d3
> So it did not stay unencrypted by mistake.
> (I assume this is one of the unreadable images.)

It looks like this for both, the readable and the unreadable discs.

> > mount -t udf -o novrs /dev/mapper/BDbackup /mnt/BDbackup
> > [62614.207920] UDF-fs: warning (device dm-10): udf_load_vrs: No anchor
> > found [62614.207922] UDF-fs: Scanning with blocksize 2048 failed
> > So now I'm stuck again, but maybe one little step later...
> 
> Yeah. Reading the anchor is a little bit further in the procedure.
> But already the missing VRS is a clear indication that the image or disc
> does not get properly decrypted when being mounted for reading.
> The VRS was there when it was mounted for writing. Later it's gone.
> 
> A UDF filesystem image is supposed to bear at its start 32 KiB of zeros.
> Have a look with a hex dumper or editor at /dev/mapper/BDbackup.
> If you see something heavily non-zero, then decryption is the main
> suspect.

This is indeed the case:

9F AC 31 11  1B EA FC 5D  28 A7 41 4E  12 B6 DA D1 | .¬1..êü](§AN.¶ÚÑ
AE 29 C2 30  ED 7D 1E 75  80 2A 1E 3D  4A 45 1C 6F | ®)Â0í}.u.*.=JE.o
78 0C 78 F1  6F 6F FB 62  A6 79 E5 50  CA 67 9F 6E | x.xñooûb¦yåPÊg.n
69 C2 86 C0  36 40 A8 62  2C F5 15 0F  83 79 B8 46 | iÂ.À6@¨b,õ...y¸F
DF 38 E7 33  0D 2D C9 59  20 4C AF 06  B1 37 80 B2 | ß8ç3.-ÉY L¯.±7.²
D8 D3 00 61  69 07 2B 4B  1D 64 20 92  4A B9 72 29 | ØÓ.ai.+K.d .J¹r)
66 65 A8 FE  F0 BF D1 1F  AC 48 2E 7B  65 42 CB 69 | fe¨þð¿Ñ.¬H.{eBËi
9B DA EC 7E  55 F3 F3 08  82 F5 A9 0F  DB D2 BD 6D | .Úì~Uóó..õ©.ÛÒ½m
2B BC 00 F5  A2 68 A2 CF  18 11 77 49  05 18 B1 18 | +¼.õ¢h¢Ï..wI..±.
C1 18 E5 CB  48 F3 C6 FF  E5 85 C3 E5  60 F9 01 81 | Á.åËHóÆÿå.Ãå`ù..
96 DA B0 44  07 A4 E6 8D  99 E0 A4 F5  6F 1F F8 2E | .Ú°D.¤æ..à¤õo.ø.
36 B4 80 19  11 1F C3 93  0A EA BC 3B  09 D7 B2 D4 | 6´Ã..ê¼;.ײÔ

For a readable disk, this look like you said: 
Only zeros.


> 
> > Thanks again for any hints...
> 
> As said, i would try whether UDF works fine without encryption.
> If yes, i would try whether dd-ing an unencryptedly populated UDF image
> into /dev/mapper/BDbackup yields images which are more reliably readable.
> 
> If UDF does not work even unencrypted, then i'd consider ext2 or ISO 9660
> as alternatives.
> (ext2 would be treated like UDF. For ISO 9660 i'd propose xorriso and
>  directing its output to the not mounted /dev/mapper/BDbackup.)

Why should UDF not work correctly without encryption?

I have an idea what might be the root cause for my problems:
As I mentioned earlier, from the small sample of discs I checked it seems that 
if I burned two discs for a backup session instead of one (too much data for 
one disc), the first one is unreadable, but the second one is readable.
With respect to the first discs it might be that during the execution of my 
script files get copied until the filesystem is full. Multi-disc backups are 
not 
handled by my script, I have to intervene manually. I never expected it to 
harm my process, moved some backup files manually, created another image which 
I burned on a second disc. So my question is basically:

Might it be possible, that when my UDF filesystem gets filled completely, the 
encryption get damaged? Or is my filesystem too large?

# Parameter:
[...]
IMGSIZE=24064000K
# There is an old comment in my script at this line, saying:
# let's try that: 24064000K
# 24438784K according to dvd+rw-mediainfo but creates at
# least sometimes INVALID ADDRESS FOR WRITE;
# alternative according to internet research: 23500M
IMGFILE=/home/TMP_BKP/backup.img
IMGLOOP=`losetup -f`

[...]

# Prepare loopback device:
echo "Preparing loopback device..."
touch $IMGFILE
truncate -s $IMGSIZE $IMGFILE
losetup $IMGLOOP $IMGFILE
echo "Creating encryption, filesystem and mounting:"
cryptsetup luksFormat --cipher aes-xts-plain64 $IMGLOOP
cryptsetup luksOpen $IMGLOOP BDbackup
mkudffs -b 2048 -m bdr --label $1 /dev/mapper/BDbackup
mount -t udf /dev/mapper/BDbackup /mnt/BDbackup

But: it's not only the burned disc which is not readable/mountable, it's also 
the image I created before burning.

Thank you once again.

Best,
Bernd

Re: Problem mounting encrypted blu-ray disc or image

[Thomas Schmitt]

Hi,

i wrote:
> > A UDF filesystem image is supposed to bear at its start 32 KiB of zeros.

B.M. wrote:
> This is indeed the case:
> [...]
> For a readable disk, this look like you said: Only zeros.

So it looks like at least a part of the problem is decryption.


> > If UDF does not work even unencrypted,

> Why should UDF not work correctly without encryption?

It's improbable, i confess.
But for now we are hunting an unexplainable problem. So we have to divide
the situation in order to narrow the set of suspects.

Verifying that your procdure with two UDF images is not the culprit would
help even if the result is boringly ok, as we expect. (Or we are in for
a surprise ...)

After the boring outcome you have the unencrypted images to make the next
step, namely to create /dev/mapper/BDbackup with a new empty image file
as base, to copy the images into it (e.g. by dd), and to close it.
Then try whether the two encrypted image files can be properly openend
as /dev/mapper/BDbackup ans show mountable UDF filesystems.


> it's not only the burned disc which is not readable/mountable, it's
> also the image I created before burning.

So we can exclude growisofs as culprit.


> Might it be possible, that when my UDF filesystem gets filled completely,
> the encryption get damaged?

That would be a bad bug in the device-mapper code and also such a mishap
is hard to imagine. The UDF driver is supposed not to write outside its
filesystem data range. That range would be at most as large as the payload
of the device mapping.


> Multi-disc backups are not
> handled by my script, I have to intervene manually.

That's always a potential source of problems.

(Around 1999 i addressed the multi-disc problem for CDs, after my manually
maintained scripts grew in number from 2 to 3.  Regrettably i see no
simple way to let scdbackup handle your special encryption wish. We'd have
to hack it a bit. And it's for ISO 9660 not for UDF, of course.)


> I never expected it to
> harm my process, moved some backup files manually, created another image
> which I burned on a second disc.

Do i get it right, that your script copies files into the mounted UDF
and gets a "filesystem full" error ?

What exactly are you doing next ?
(From where to where are you moving the surplus files ?
Does the first /dev/mapper device stay open while you create the encrypted
device for the second UDF filesystem ? Anything i don't think of ... ?)


>  Or is my filesystem too large?

25 "GB" would rather be too small to swim in the swarm of other cryptsetup
users.


---
Slightly off topic: A riddle about your UDF image sizes:

> # There is an old comment in my script at this line, saying:
> # let's try that: 24064000K
> # 24438784K according to dvd+rw-mediainfo but creates at
> # least sometimes INVALID ADDRESS FOR WRITE;
> # alternative according to internet research: 23500M

An unformatted single layer BD-R has 12,219,392 blocks = 23866 MiB =
24,438,784 KiB.
But growisofs formats it by default to 11,826,176 = 23098 MiB =
23,652,352 KiB.

growisofs_mmc.cpp emits a message in function bd_r_format()
fprintf (stderr,"%s: pre-formatting blank BD-R for %.1fGB...\n",
ioctl_device,(f[0]<<24|f[1]<<16|f[2]<<8|f[3])*2048.0/1e9);
Watch your growisofs run for it.
(Note that it talks of merchant's GB = 1 billion, not of programmer's
 GiB = 107.3741,824. 23098 MiB = 24.220008448 GB)


> IMGSIZE=24064000K
> truncate -s $IMGSIZE $IMGFILE

The man page of truncate says that it's "K" are 1024, i.e KiB.
So your image has 23500 MiB which is too large for the default format
as normally applied to BD-R by growisofs.

growisofs has a bug to accept burn jobs which fit into unformatted BD-R
but then to spoil them by applying its default format:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699186

So how come that your growisofs run does not fail in the end ?

There is an undocumented growisofs option to suppress BD-R formatting:
  -use-the-force-luke=spare=none
There is also
  -use-the-force-luke=spare=min
which (i guess) will bring 23610 MiB of payload.

(I take the occasion to point out that xorriso does not format BD-R
by default. I.e. default capacity is 23866 MiB.)


Have a nice day :)

Thomas

Re: nft newbie

[Tom Browder]

On Wed, Jul 6, 2022 at 7:17 PM Will Mengarini  wrote:
>
> * gene heskett  [22-07/06=We 18:50 -0400]:
> > [...] iptables is out of support, replaced I
> > guess with nft.  [...] whats the command to [...]

The nft is too complicated. UFW works great and is so easy.

-Tom

Re: nft newbie

[gene heskett]

On 7/7/22 10:13, Tom Browder wrote:

On Wed, Jul 6, 2022 at 7:17 PM Will Mengarini  wrote:

* gene heskett  [22-07/06=We 18:50 -0400]:

[...] iptables is out of support, replaced I
guess with nft.  [...] whats the command to [...]

The nft is too complicated. UFW works great and is so easy.

-Tom

.
People said that about iptables too, but once you understood how it 
worked, you could block all
of a given outfits possible bot addresses with one /8 or /16, in one 
case a /24. If that denies
one of their legit customers too, I usually told them to fuss at their 
isp as it was not respecting
my robots.txt. Now we've a new name in bots we'll have to train. Look at 
your access logs, it'll

stick out like a sore thumb.

But now I need to create another robots.txt. The worst part of that is 
the stubborn ones will scan
for subdirs that don't have a robots.txt and will bypass the www/root so 
you need a robots.txt in

every dir. That ability I blame on apache2.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

need to know where to file a bug or ask a question.

[tmcconnell168]

Hi list,
I've been having a problem with reading local email (like Cron reports
etc.) and I tracked it down to either Evolution or WebKitWebProcess.
I've opened bugs with both and have been talking with the Evolution
mailing list. Milan Crha from that list had me run some backtraces and
all he can see is both of them are showing "Both have threads related
to your graphics drivers (/usr/lib/x86_64-linux-
gnu/dri/radeonsi_dri.so), maybe that is part of the problem you face."

As far as I know I'm supposed to be using radeon.cik_support 0r
amd.cik_support for GPU drivers. If that is what's causing my CPU to go
to 100% usage when I read local mail then I need to know how to correct
that? 
Thanks for taking the time to read this and help answer the question. 

Tim
-- 
 

Re: CVE Applicability Inquiry

[Griffin Weikel]

Good Afternoon,

Following-up to confirm the information below. Please advise if able.

Thank you,

Griffin

Griffin Weikel
Security Risk Engineering Manager
M: (443) 745-4594

servicenow.com
LinkedIn  | 
Twitter  | 
YouTube | 
Facebook


From: Griffin Weikel 
Date: Wednesday, June 29, 2022 at 2:30 PM
To: debian-user@lists.debian.org 
Cc: Tim Nelson , Christopher Engel 

Subject: CVE Applicability Inquiry
Good Afternoon,

I’m writing to inquire about the applicability of a couple CVEs to the Bullseye 
release. The two CVEs below are popping in our Prisma scans as vulnerable, 
however I noticed on the Debian site that Bullseye isn’t listed. This seemed to 
deviate from the majority of CVEs we’re reviewing. Are you able to confirm that 
if a CVE page doesn’t list a release in the tracker that we’re to assume the 
release isn’t vulnerable?

https://security-tracker.debian.org/tracker/CVE-2022-24675
https://security-tracker.debian.org/tracker/CVE-2022-28327

Also, confirming my email subscription via CONFIRM s2022062918105226032.

Thank you,

Griffin

Griffin Weikel
Security Risk Engineering Manager
M: (443) 745-4594

servicenow.com
LinkedIn  | 
Twitter  | 
YouTube | 
Facebook

Re: CVE Applicability Inquiry

[Roberto C . Sánchez]

Hi Griffin,

This is the user mailing list and might not be the best forum for this
type of question.  That said, according to the Debian package search[0],
bullseye has golang-1.15, while the two CVEs you reference are noted as
affecting golang-1.17 and golang-1.18.  So, to answer your question, if
a particular suite is not present in the entry for a CVE, then that
means that security team has not assessed it as affecting any package in
that suite.  You can view information about the open and resolved CVEs
associated with golang-1.15 in the security tracker as well [1].

Regards,

-Roberto

[0] 
https://packages.debian.org/search?suite=bullseye&searchon=sourcenames&keywords=golang-1
[1] https://security-tracker.debian.org/tracker/source-package/golang-1.15

On Thu, Jul 07, 2022 at 07:17:18PM +, Griffin Weikel wrote:
>Good Afternoon,
> 
> 
> 
>Following-up to confirm the information below. Please advise if able.
> 
> 
> 
>Thank you,
> 
>Griffin
> 
> 
> 
>Griffin Weikel
> 
>Security Risk Engineering Manager
> 
>M: (443) 745-4594
> 
> 
> 
>[1]servicenow.com
> 
>[2]LinkedIn   | [3]Twitter  | [4]YouTube | [5]Facebook
> 
> 
> 
> 
> 
>From: Griffin Weikel 
>Date: Wednesday, June 29, 2022 at 2:30 PM
>To: debian-user@lists.debian.org 
>Cc: Tim Nelson , Christopher Engel
>
>Subject: CVE Applicability Inquiry
> 
>Good Afternoon,
> 
> 
> 
>I’m writing to inquire about the applicability of a couple CVEs to the
>Bullseye release. The two CVEs below are popping in our Prisma scans as
>vulnerable, however I noticed on the Debian site that Bullseye isn’t
>listed. This seemed to deviate from the majority of CVEs we’re reviewing.
>Are you able to confirm that if a CVE page doesn’t list a release in the
>tracker that we’re to assume the release isn’t vulnerable?  
> 
> 
> 
>[6]https://security-tracker.debian.org/tracker/CVE-2022-24675
> 
>[7]https://security-tracker.debian.org/tracker/CVE-2022-28327
> 
> 
> 
>Also, confirming my email subscription via CONFIRM s2022062918105226032.
> 
> 
> 
>Thank you,
> 
>Griffin
> 
> 
> 
>Griffin Weikel
> 
>Security Risk Engineering Manager
> 
>M: (443) 745-4594
> 
> 
> 
>[8]servicenow.com
> 
>[9]LinkedIn   | [10]Twitter  | [11]YouTube | [12]Facebook
> 
> 
> 
> References
> 
>Visible links
>1. https://www.servicenow.com/
>2. https://www.linkedin.com/company/servicenow
>3. https://twitter.com/servicenow
>4. https://www.youtube.com/user/servicenowinc
>5. https://www.facebook.com/servicenow
>6. https://security-tracker.debian.org/tracker/CVE-2022-24675
>7. https://security-tracker.debian.org/tracker/CVE-2022-28327
>8. https://www.servicenow.com/
>9. https://www.linkedin.com/company/servicenow
>   10. https://twitter.com/servicenow
>   11. https://www.youtube.com/user/servicenowinc
>   12. https://www.facebook.com/servicenow

-- 
Roberto C. Sánchez

Re: odd name of LUKS partition

[Piscium]

On Wed, 6 Jul 2022 at 03:19, Piscium  wrote:

> I won't bother changing the name, I was just curious.

In the end I changed the name of the LUKS partition. It was easy. I am
posting here the commands in case someone else is interested.

As root:
1. dmsetup rename /dev/mapper/oldname newname
2. edit /etc/crypttab, replace oldname with newname
3. update-initramfs -k all -u
4. reboot

Re: odd name of LUKS partition

[David]

On Fri, 8 Jul 2022 at 07:25, Piscium  wrote:
> On Wed, 6 Jul 2022 at 03:19, Piscium  wrote:

> > I won't bother changing the name, I was just curious.
>
> In the end I changed the name of the LUKS partition. It was easy. I am
> posting here the commands in case someone else is interested.
>
> As root:
> 1. dmsetup rename /dev/mapper/oldname newname
> 2. edit /etc/crypttab, replace oldname with newname
> 3. update-initramfs -k all -u
> 4. reboot

Oh wow, that's great. I was not aware of 'dmsetup rename'.

Before that, the only way I had found to rename the opened
LUKS volume involved closing it, which is obviously trickier
given that it contains the running operating system.

Thank you very much for sharing that information.

It's my understanding that the name in question is just a
string that sits in /etc/crypttab to provide the 
used by
  cryptsetup open  
command. The tricky part is that this command does
occur in the initrd, becaue the the root filesystem must be
decrypted before it is provided to the kernel command
line.