No, file system permissions are enforced by the operating system.
When a program wants to delete a file, it calls the unlink() function, which immediately turns control over to the kernel. The kernel first checks to see if the file exists, and then checks the permissions associated with it. If the user has permission to delete (which typically means write permission on the directory containing the file), then the kernel will, using the filesystem driver, perform all the necessary actions to remove the file from the disk. Once this is done, control is then returned back to the user's program.
This distinction between actions performed directly by your program (typically called "user mode" or "user land") and actions performed by the kernel on behalf of the user (typically called "kernel mode") are a key feature of all operating systems, not just Linux, and is the basis of how kernel rules are enforced, including process separation, privilege separation, memory segmentation, and everything that the kernel is responsible for providing.
Any flaw or loophole that would allow a program to circumvent this protection would be considered a privilege escalation vulnerability, and would have to be fixed for the OS to be safe to use. These are surprisingly common, but typically get fixed quickly once discovered.
With respect to filesystem privileges, the thing that prevents you from writing your own filesystem driver to circumvent the kernel's filesystem driver is the fact that a user doesn't have direct read or write access to the raw disk. These rights are controlled (once again) by filesystem permissions.
On Linux and Unix systems, there are a set of special files which represent physical devices, typically kept in the
/dev/ directory. For example,
/dev/sda represents the first SCSI or SATA disk on Linux. On BSD (including OSX) it's
Reading or writing these files will actually read or write directly to the disk, skipping the filesystem driver, but still going through the kernel. Since these files have their own permissions set to them, the very same checks are performed by the kernel before allowing access to the device, so the security remains intact.
If you were to change the permissions or ownership of the entry in
/dev/ to allow ordinary users direct disk access, by doing so you would create (you guessed it) a privilege escalation vulnerability.