3 ms·

> sending uid assurance This sounds like an attempt to implement security features the kernel already provides. Why would you need an assurance of a UID, and

by pdkl95 11y ago

> sending uid assurance This sounds like an attempt to implement security features the kernel already provides. Why would you need an assurance of a UID, and why would you assume that it would stay accurate? Using UIDs to do manual security features is going to have reliability issues, and if it's for a non-security feature, you don't need an assurance.

viraptor 11y ago
Yes it is for security features. Services get your message and if they operate on system resources they need to know who you are so they can either execute some action or not. Sure, this can be pushed to other layers instead (selinux for example), but it doesn't change that the functionality is needed. This impacts issues like configuring wireless networks without being an admin. (which is what most people want in practice)
- pdkl95 11y ago
  I get that you want to use UIDs for these things, but that's wishful thinking. You're assuming properties about a process's UID that are not guaranteed. See setuid(2) for example, or passing an fd from another process. The reason you leave these things to the kernel is the kernel is the only place that can actually make the proper security determination. A file-permission analogy: it is a bad idea to stat(2) a file to probe if it's possible to open it. The kernel already provides that capability, which you have to handle anyway. The proper design is to open the file, and handle the EACCES error. Testing first doesn't work because the situation can change between the stat(2) and the open(2). > configuring wireless networks There are many ways to handle that, which do not require abusing UIDs for security features they weren't designed for. edit: No, I absolutely am not agreeing with you. Using UIDs for security outside the kernel (which is where the assurances your new kernel feature would provide will end up) is fundamentally broken. It works inside the kernel because the kernel can lock whatever is necessary. You are only moving the race condition. You ask your new interface for the sender's UID, an interrupt happens, and the data you got may no longer be valid as the sender called setuid().
  - viraptor 11y ago
    So you're agreeing with me. Exactly one of the reasons kdbus was being pushed - because only a kernel-owned bus can give you any guarantees about who sent the message. And the stat()-like race is exactly why userland dbus cannot provide this. The way it's been proposed in kdbus is not by querying. Messages simply get the additional information attached to them so it's guaranteed to be correct at the time of sending.

by pdkl95 11y ago

viraptor 11y ago

Yes it is for security features. Services get your message and if they operate on system resources they need to know who you are so they can either execute some action or not. Sure, this can be pushed to other layers instead (selinux for example), but it doesn't change that the functionality is needed. This impacts issues like configuring wireless networks without being an admin. (which is what most people want in practice)

pdkl95 11y ago
I get that you want to use UIDs for these things, but that's wishful thinking. You're assuming properties about a process's UID that are not guaranteed. See setuid(2) for example, or passing an fd from another process. The reason you leave these things to the kernel is the kernel is the only place that can actually make the proper security determination. A file-permission analogy: it is a bad idea to stat(2) a file to probe if it's possible to open it. The kernel already provides that capability, which you have to handle anyway. The proper design is to open the file, and handle the EACCES error. Testing first doesn't work because the situation can change between the stat(2) and the open(2). > configuring wireless networks There are many ways to handle that, which do not require abusing UIDs for security features they weren't designed for. edit: No, I absolutely am not agreeing with you. Using UIDs for security outside the kernel (which is where the assurances your new kernel feature would provide will end up) is fundamentally broken. It works inside the kernel because the kernel can lock whatever is necessary. You are only moving the race condition. You ask your new interface for the sender's UID, an interrupt happens, and the data you got may no longer be valid as the sender called setuid().
- viraptor 11y ago
  So you're agreeing with me. Exactly one of the reasons kdbus was being pushed - because only a kernel-owned bus can give you any guarantees about who sent the message. And the stat()-like race is exactly why userland dbus cannot provide this. The way it's been proposed in kdbus is not by querying. Messages simply get the additional information attached to them so it's guaranteed to be correct at the time of sending.