Would generation of SELinux policies be a good use case for LLMs?
"Generate a SELinux policy for daemon X. This daemon accesses it's config file in /etc and it's runtime data in /var/x. It listens on network. All other activities should be disabled"
While I agree the syntax of the policy is a big part of the difficulty, I think it's equally difficult for many apps/services to find out what activities it needs.
> We furthermore propose that pages on websites that have information that might be useful for LLMs to read provide a clean markdown version of those pages at the same URL as the original page, but with .md appended.
Not happening, that's like asking websites to provide an ad-free, brand identity free version for free. And we can't have that now can we
While author said that C's mmap suffers the same issue, I would argue C's mmap is fine, because C doesn't have async. The issue arises from the mmap crate not having an async read and the confusion around how does async work.
I think what rmholt means is that ruroco does not improve security in the sense, that it has stronger and safer encryption/algorithms/... but that it merely "hides" existing services.
I would argue that it does improve security in the way that it reduces the attack surface of potential vulnerable services, because they are simply not accessible for adversaries.
On the other hand, having another tool running increases the attack surface, but imho that's very small.
Yup that's what I meant! And I am worried that a replay attack would be able to bypass ruroco. Thus ruruco is not a replacement for good SSH security, which you have to do anyway.
But like I wanna stress that I like ruroco and I might end up using it to decrease the internet noise on my home lab, but I'm just worried that someone might end up relying on ruroco instead of proper SSH security
a replay attack won't work, because every UDP packet data has deadline in nanoseconds.
Once this UDP packet reaches the server the deadline will be added to the blocklist.
If an attacker sends the same packet again, the server will check its blocklist for the deadline. It does not matter if the deadline has been reached or not. once the packet reaches the server, the deadline of that packet will be added to the blocklist.
The encrypted information is current time, command and random data. So the server could feasibly detect that a retransmission has occurred but that's about it.
reply