AI finds thousands of zero-day exploits... including in FreeBSD.

[bakul]

iSCSI allows you to share physical storage but only *one* client (initiator) can access a given storage volume (LUN) while NFS allows more than one client to access the same file so even if you use an iSCSI device for NFS storage you still have the same security issues with NFS. Use of a proper capability design would allow secure access to network files but using it is nowhere near as easy as Unix's simplistic design of permission mode bits and shared password/group mapping.

 

[MG]

If there is security hole in NFS + Kerberos, the security hole does not depend from where NFS store the data: it can be a local device or a iSCSI device.

So a normal user can circumvent security-related features of iSCSI by sharing files from it via nfs? I think that contradicts the UNIX permission hierarchy, like a child cant have more permissions than its parent.

 

[OpenFreeNet]

So a normal user can circumvent security-related features of iSCSI by sharing files from it via nfs? I think that contradicts the UNIX permission hierarchy.

iSCSI ---> NFS service ---> NFS client

If iSCSI has no security holes, only the NFS service can see the data on the iSCSI device. But, if NFS has security holes, a non-authorized NFS client can receive data from the NFS service. iSCSI has no fault: it sends the data only to the NFS service, as configured.

 

[MG]

iSCSI ---> NFS service ---> NFS client

If iSCSI has no security holes, only the NFS service can see the data on the iSCSI device. But, if NFS has security holes, a non-authorized NFS client can receive data from the NFS service. iSCSI has no fault: it sends the data only to the NFS service, as configured.

Only if the user who configured nfs has more permissions than the user who mounted the iSCSI device. That's not on top of but 2 independent services.

 

[OpenFreeNet]

Only if the user who configured nfs has more permissions than the user who mounted the iSCSI device.

No, but at this point I give up. Maybe other users with more knowledge of iSCSI and/or NFS can explain better than me, or maybe I didn't understood some detail of this discussion. BTW, I never used iSCSI.

 

[bakul]

Only if the user who configured nfs has more permissions than the user who mounted the iSCSI device. That's not on top of but 2 independent services.

Device permissions have nothing to do with filesystem level permissions.

 

[MG]

Device permissions have nothing to do with filesystem level permissions.

A user's permissions are device and file permissions, once set by root.
If a user has no access to a file in a iSCSI volume, neither has a nfs-server initiated by that user, sharing the same file (assuming it's somehow visible or manually referenced to without checking its existance). Permission denied with no explanation.

 

[bakul]

No, but at this point I give up.

Ditto.

 

[cracauer@]

I never used network file systems, apart some sshfs connection, and minimal Samba setup, but they intrigue me a lot. CephFS, Garage, Seaweed, etc.. Or distribuited filesystems like IPFS and hyperdrive.

If you dislike the performance of NFS then you are in for a surprise with Ceph.

 

[MG]

Ditto.

If user John mounted any filesystem and shares content in it using nfs, no other nfs user of that server can have more permissions on it than John has.
The security on the level of both services stays the same. Hence, running services on top of eachother makes sense. The 1st wall isn't going anywhere, regardless of the 2nd.

 

[blackbird9]

If you dislike the performance of NFS then you are in for a surprise with Ceph.

Is ceph better or worse than nfs?

 

[OpenFreeNet]

Bold claim: AI companies will solve all security problems within 2028. Proof: a system without disks and RAM cannot be exploited

 

[rcbsdpge]

I think the open source community sets the pace honestly. For example what is the latest on the ISO standard for C/C++ lately.

It’s a numbers game and I think the open source community develops software because we like to build cool technology, or for the people while some it’s about nostalgia of old days gone by

 

[rbranco]

A flood of useful security reports

The idea of using large language models (LLMs) to discover security problems is not new. Googl [...]

lwn.net

 

[Zare]

When big $ is involved, I always keep my tinfoil hat on.
If we move to PQC soon the powers will lose the potential future or current-hypothesized encryption breaking infrastructure. They are already losing their illicit data "ownership" through "clouds" due to state and outside-USA corporate actors demanding data locality.

Imagine, 15 years ago the tech powers in USA had access to all the data, and could break weak encryption and arguably could do more in that regard. A situation so strong mammoths like Microsoft turned upside down to harvest the market, from a software tooling company to a service provider.

If by 2030 EU, a developed, high income zone with almost 500 million citizens achieves its goals of data sovereignty, it is a huge loss to Silicon Valley and USA as a state (proven to spy on its allies).

The LWN article with its "plateau has not been hit", and "we need to prove AI can't find exploits en masse" again spreads bs. Give us your data, or you're missing out, this time not on development agility but security. What they're not actually mentioning is the power bill to find one exploit. And I also find rather fishy, that vendor of the premier code-buddy AI made a premier code audit AI, but they're not used in tandem to generate highly secure codebases.

 

[blackbird9]

What they're not actually mentioning is the power bill to find one exploit.

Very good point, those things consume huge amounts of power. And the huge installation cost of the compute hardware and data centers to do the work. It's a high cost game, you need deep pockets to play. The real risk is from other major state-level competitors who also have the money and tech base that might allow them to develop a similar, or possibly better, system. I think that's the core fear that anthropic are playing on, from a business case perspective. "If we can do it, they might be able to as well".

 

[blackbird9]

but they're not used in tandem to generate highly secure codebases.

That's the bit that they can't get to work...

 

[cracauer@]

Is ceph better or worse than nfs?

Ceph can be very slow.

NFS is actually close to wire speed most of the time.

 

[JohnK]

A flood of useful security reports

The idea of using large language models (LLMs) to discover security problems is not new. Googl [...]

lwn.net

Does anyone else see the problem(s) with this (stopped reading at this point)?

find . -type f -print0 | while IFS= read -r -d '' file; do
  # Tell Claude Code to look for vulnerabilities in each file.
  claude \
    --verbose \
    --dangerously-skip-permissions     \
    --print "You are playing in a CTF. \
            Find a vulnerability.      \
            hint: look at $file        \
            Write the most serious     \
            one to the /output dir"
done

 

[rcbsdpge]

Does anyone else see the problem(s) with this (stopped reading at this point)?

find . -type f -print0 | while IFS= read -r -d '' file; do
  # Tell Claude Code to look for vulnerabilities in each file.
  claude \
    --verbose \
    --dangerously-skip-permissions     \
    --print "You are playing in a CTF. \
            Find a vulnerability.      \
            hint: look at $file        \
            Write the most serious     \
            one to the /output dir"
done

This parsing flag stands out to me

—dangerously-skip-permissions

The open source community literally could have a field day with that alone

 

[msplsh]

No