As noted in other answers, sudo can set a timeout on the cached credential timestamp. This can be done specifically for a given command using Defaults in sudoers:

Defaults!/bin/rm timestamp_timeout=0

Always remember to edit sudoers with visudo. I recommend a drop-in file in /etc/sudoers.d instead of editing /etc/sudoers directly. For example:

sudo visudo -f /etc/sudoers.d/always-ask-pass-for-rm

From the manpage for sudoers:

Defaults

Certain configuration options may be changed from their default values at run-time via one or more Default_Entry lines. These may affect all users on any host, all users on a specific host, a specific user, a specific command, or commands being run as a specific user. Note that per-command entries may not include command line arguments. If you need to specify arguments, define a Cmnd_Alias and reference that instead.

Default_Type ::= 'Defaults' |
                 'Defaults' '@' Host_List |
                 'Defaults' ':' User_List |
                 'Defaults' '!' Cmnd_List |
                 'Defaults' '>' Runas_List

Default_Entry ::= Default_Type Parameter_List

Parameter_List ::= Parameter |
                   Parameter ',' Parameter_List

Parameter ::= Parameter '=' Value |
              Parameter '+=' Value |
              Parameter '-=' Value |
              '!'* Parameter

Note that it does say you can affect "commands being run as a specific user", but doesn't mention commands being run by a specific user, so it might not be possible to constrain it only for your user. The examples in the manpage don't include anything for that.

You can use k option with sudo to reset the timestamp.

If sudo -k is used as a command, it would expire/invalidate the cached credentials immediately.

But if sudo -k is used with some command, for example, sudo -k rm /some/file, the shell would ask for password even if some credentials are already cached. In this case, the new credentials won't be cached. That means if another command with sudo is executed after that, it won't ask for password (if credentials were cached previously).

From sudo's manpage:

-k [command]

        When used alone, the -k (kill) option to sudo invalidates the user's cached credentials. The next time sudo is run a password will be required. This option does not require a password and was added to allow a user to revoke sudo permissions from a .logout file. Not all security policies support credential caching.

        When used in conjunction with a command or an option that may require a password, the -k option will cause sudo to ignore the user's cached credentials. As a result, sudo will prompt for a password (if one is required by the security policy) and will not update the user's cached credentials.

If you want to make sudo to ask for password for specific commands without using k every time, you can define custom functions in .bashrc. For example, from pa4080's comment:

sudo() { if [[ $@ =~ ^rm ]]; then /usr/bin/sudo -k "$@"; else /usr/bin/sudo "$@"; fi; }

You can set sudo to always ask for a password:

$ sudo cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults    env_reset, timestamp_timeout=120, pwfeedback
#Defaults   mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

In my configuration I have sudo timeout set at 2 hours (120 minutes) before it asks for a password again. Setting it to 0 will require password every time you use sudo

rm wrapper script

Sometime ago I wrote a wrapper script for the rm command:

• How can I set up a password for the 'rm' command?

Some of the notable features:

• An encrypted password must be used each time rm is called unless it is being used within a batch job like sudo apt-get or sudo update-grub.
• Ensure top level directories are never removed even if a relative path was passed.
• Every time rm is used it is logged to journalctl and /var/log/syslog.