Root access to Ubuntu when you have a access to sudoer’s desktop, but not to his root password

It is true that someone who has physical access to your hardware can't be stopped from accessing the system. In most cases, I'd think all you have to do is replace /etc/passwd and now it's cracked. I imagine this is a little trickier if the entire filesystem beyond the kernel is encrypted. I believe that is possible but I have not done it; maybe someone else will chime in.

Gaining root access to the system, however, does not necessarily allow you to decrypt anything and everything.

I'm not a user of keyrings, but if, as you say, your encrypted folder is mounted and decrypted by a login, that is not very secure at all from this perspective, since gaining root access will circumvent that mechanism.

I do encrypt things; unfortunately I do it programmatically, so I don't have any end user software to recommend, but I can outline some concepts (and I'm sure there is end user software for this if you look; hopefully this info will help you understand what it's for and how to use it). Strongly encrypted data requires a key, which is sort of just a really big password -- e.g., if you have generated SSH keys before (exact same idea), they are usually 2048 bits, which would be 292 ASCII characters. That means there are:

2^(2048) = 32317006071311007300714876688669951960444102669715484032130345427524655138867890893197201411522913463688717960921898019494119559150490921095088152386448283120630877367300996091750197750389652106796057638384067568276792218642619756161838094338476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656

possible such keys. Now, if you had a house full of computers and could somehow attempt to brute force something encrypted with a key like that 1000000 times per second, there are 60*60*24*365=31536000 seconds in a year and so the longest it should take to crack the encryption is: 1024765540059329252305773613922816842987192499673880138005147939736322144180234997881697152826069046920621447264139333444131137720398621292969563431838162199411176983996099571656208705935744929819763370065451153230491889226364147519084160779378366643536962387494809266961173766220860787944176572777902409485093681297237073262959315537372037338116951294879703261608251067330385153244179994740939199418574870520229058971285573863444899516498656960438980771601765830518363954994635344042527812713309592956293713298473385906108764499884354345453308129324880686692782919058638686093522275450436077758547560046

years. Of course, there are I believe much better strategies than brute force, but even if you cut that time by a factor of a billion, don't hold your breath.

That's on purpose -- these are hard core encryption algorithms, some of which were commissioned (and I guess are used) by the US military (which is why there is sometimes weird "export regulations" regarding them). They're effectively unbreakable, period. In war your opponent can potentially gain physical access to your hardware, but if your tish is encrypted and they don't have the key, they're stuck.

So one obvious and easy way to secure encrypted data on your laptop in case it gets stolen is to not leave the encryption key on it. Instead, you put it on a USB stick.

But what if someone gets the laptop and the whatever with the key on it (since it does have to be somewhere, you can't memorize it)? You password encrypt the key. You now have a weak link in the chain, though, because a 16 character ascii password only has 2^(7*16) = 5192296858534827628530496329220096 possibilities, meaning the brute force max @ 1000000 attempts/second is a measily 164646653302093722365 years. I think the number of attempts per second has to slow down though, because in order to test the cracked key they have to apply it to the encrypted data.

What I'm trying to say is: if the decryption is tied to a user login, yes anyone who grabs the hardware can easily crack it. I don't know if that is actually what gnome is doing, but probably, since it cannot get your password (those are one way encrypted, see NOTE) and use that (if it could, that would be smarter, because now if someone changed the password, your login would simply fail to decrypt the folder, and that would be that). But there are options, if you have stuff you really need to protect. [lightbulb: It may be that what gnome does is encrypt using the scrambled form (anything will do) when you logout, then decrypts it when you log in. A way to test this might be to log the user completely out, then log in as root and change the user password with passwd username. Or you could just ask the gnome people about this issue.]

NOTE: One way encryption means a method that is not reversible, but always produces the same result. So, you enter your password and it is transformed and the product of that transformation is compared to what is on record (ie, what is on record is not your password!). If they match, good. But if they don't, there is no way to take what's on record in /etc/passwd and turn it back into your password. That's "one way" encrytion. Obviously it is no good for data, because whatever you encrypt that way is irretrievably lost, but it is the standard way of storing passwords (although I think some big companies that should know better, such as Apple, have actually been caught, post hack, as having not done this for some absurd reason, and stored customer passwords in plain text).

We want that some users should be able to do e.g. sudo and become root,

Well, that's the problem sudo is designed to solve, so that part is easy enough.

but with the restriction that the user can't change root password.

You can, as SHW pointed out in a comment, configure sudo to only allow certain actions to be taken as root by certain users. That is, you can allow user1 to do sudo services apache2 restart, allow user2 to do sudo reboot but nothing else, while allowing the hired-as-system-administrator user3 to do sudo -i. There are howtos available on how to set up sudo like that, or you can search (or ask) here. That is a solvable problem.

However, a user that has been granted the ability to sudo -i or sudo into a shell (sudo bash, for example) can do anything. That is because by the time sudo launches the shell, sudo itself is out of the picture. It provides the security context of a different user (most often root), but has no say in what the executed application does. If that application in turn launches passwd root there is nothing sudo can do about it. Note that this can be done through other applications, too; for example, many of the more advanced editors provide facilities to execute a command through the shell, a shell which will be executed with the effective uid of that editor process (that is, root).

That is, a guarantee that we still can login to that server and become root no matter of what the other users will do.

Sorry; if you really do mean "ensure we'll be able to log in and use the system no matter what someone with root access does to it", that (for all intents and purposes) cannot be done. A quick "sudo rm /etc/passwd" or "sudo chmod -x /bin/bash" (or whatever shell root uses) and you are pretty much hosed anyway. "Pretty much hosed" meaning "you'll need to restore from backup and hope they didn't do anything worse than a slip of fingers". You can take some steps to reduce the risk of an accidental mishap leading to an unusable system, but you cannot prevent malice from causing very serious problems up to and including the point of needing to rebuild the system from scratch or at the very least from known good backups.

By giving unfettered root access on a system to a user, you trust that user (including any software they might choose to execute, even something as mundane as ls) to not have malicious intent, and to not mess up by accident. That's the nature of root access.

Limited root access through e.g. sudo is a bit better, but you still have to be careful to not open up any attack vectors. And with root access, there are plenty of possible attack vectors for privilege escalation attacks.

If you can't trust them with the level of access that being root entails, you'll need either a very tightened down sudo configuration, or to simply not grant the user in question root access at all through any means, sudo or otherwise.