| View previous topic :: View next topic |
| Author |
Message |
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
 Posted: Sun Jan 11, 2015 7:15 am Post subject: |
 |
|
This is just a thought, but is calculating the SHA256 really important at boot time? I'm not saying having SHA256 is a bad thing or why having SHA256 in general. It's more of how important is it, for the need to able to calculate that when the system is still in such a early stage of booting up? If you can push the need to after the point the file system tree has been initialized, I don't think the issue about linking to a library in /usr is going to matter (considering the system is already up).
This is only a theoretical thought, I haven't looked at the code and stuff to see how feasible doing this is. |
|
| Back to top |
|
 |
judecn
n00b
Joined: 07 Jan 2015
Posts: 17
|
| Posted: Sun Jan 11, 2015 7:45 am Post subject: |
|
|
Hi ct85711,
It has to do with the way vdev performs per-process access control. By using FUSE to handle requests to /dev, vdev learns the task ID of the requester and can equivocate about what it knows (i.e. it can tell an unprivileged process that the requested device node doesn't exist). However, the task ID isn't really useful for defining ACLs a priori, since it's different each time the program runs. Instead, the admin needs to identify processes to vdev in a consistent way, so vdev can consistently apply the ACL to it.
The process identifiers can be somewhat varied in practice, since the things that uniquely identify a process depend on the situation. At the time of this writing, vdev supports identifying a process by path, by its binary's inode number, by a program of the admin's choosing that can print the process's PID to stdout, and by the process binary's SHA256 (this is where the SHA256 dependency comes in). For example, if the admin wants to stop all instances of a program from accessing a device node, regardless of where it is installed, identifying the process by its binary's SHA256 could be a way to do so.
Maybe it will turn out that using the SHA256 will be a useless feature that can be removed. In fact, while writing this it became clear that if the admin can supply a program that prints the process's PID, and if vdev can be modified to give that program the task ID (and/or whatever information it learns about the process from /proc), the admin can simply write a script that calculates the SHA256 of the binary and only prints the PID if it does *not* match the blacklisted SHA256. Hmmm.... |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Jan 11, 2015 9:14 am Post subject: |
|
|
Or you can just add the SHA256 function to your program (if the lib license allow that).
If you really need it, but just this function, you can have both: the function from the lib but not a link with the lib
Having your own copy of a lib put more work (as you must update vdev to follow security patch from that lib), but having your own lib copy could also be a solve (in case you really cannot manage to grab the function only). |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jan 11, 2015 4:42 pm Post subject: |
|
|
| judecn wrote: | | Multi-seat setups and dependencies on a device manager are an evolutionary dead end. (Thanks to steveL for bring this up). |
You're misinterpreting me. I never said multi-seat setups are a dead-end (or if I did, I said it badly: it's a dead-end for the coder, not the user.) I simply indicated that it is nothing which needs anything major. Firstly to do it right you use LTSP. Secondly, to kludge it on a desktop you just need to mark device nodes so that X knows which USB hub they're attached to. This is nothing new, and simply an application of whatever userland agent is listening to netlink. The main point being, "multi-seat" does not require systemd, nor does it require anything else we don't already have.
So if it's a focus of your design, as it appears to be from your site, with respect I think you're getting caught up in the hype. And that will lead to you wasting time, as well as thinking that it is an aid to "reasoning". From where I'm sitting it's actually a distraction from the task at hand, a side-path that has been signposted by someone who isn't on your side at all.
My main point was in fact that "equivocating" process' access to device nodes, as you put it, is a dead-end, since that is the kernel's job. And you're still going on about it, as if I never said that at all, and as if it is the correct thing to do. It is not. It is in fact an earlier example of a pretext selling-point, and by accepting that as a design, you're simply following systemd in doing it wrong, afaic.
My point stands: if you take those two out of the equation, as in stop worrying about them as things you have to deal with because someone else said they're needed, and that they somehow necessitate or justify all these other borkages; the design would be a lot cleaner and simpler.
It took me 25 years before I really started to appreciate that as a modus operandi. When you're young, it seems like a cop-out[1]. But it's not: it is in fact how to do it right, I now see. Strip away everything that is not needed, and what remains is what you must do, and do well.
I have no idea where you are in your career, and I'm not making any judgements or statements about you personally.
For anyone who's considering programming, I sincerely hope it doesn't take you that long to let go of your ego in respect of your code.
Just bear in mind: the second system effect means that you should plan to throw two away.
[1] "Surely if I take care of extra things, and provide more convenience, that's better right?" |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10589
Location: Somewhere over Atlanta, Georgia
|
| Posted: Sun Jan 11, 2015 4:43 pm Post subject: |
|
|
| judecn wrote: | | John R. Graham wrote: | | But frankly, if you think it's a compelling feature, SHA256 is a manageable amount of source code to incorporate from another project, even the OpenSSL project. You have a solvable problem on your hands. |
That's probably what I'll end up having to do for libpstat, since the SHA256 implementation can't live in /usr. I'm just not a fan of NIH syndrome, so I consider this to be an approach of last resort (but it looks like I'm there now). |
I think you can safely consider the SHA256 implementation to be firmly "NIH", which still leaves you as a squeaky clean open source citizen. Yon can even have your build system unpack (and, if necessary, fetch) the source code tarball so the external implementation is still logically incorporated by reference.
Looked at another way, if there are legitimate technical reasons for this approach, don't sweat it.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Sun Jan 11, 2015 5:22 pm Post subject: |
|
|
| judecn wrote: | | For example, if the admin wants to stop all instances of a program from accessing a device node, regardless of where it is installed, identifying the process by its binary's SHA256 could be a way to do so. |
... would it be better to get the admin to whitelist binaries rather than trying to blacklist based on a hash which could be changed? |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Sun Jan 11, 2015 7:35 pm Post subject: |
|
|
| I don't really see why you would need to have vdev like as the device manager and a cop at the same time. Because my thoughts of security is much different then others, I'll not argue on that due to my lack of understanding on other's security needs. Maybe once I have a better understanding on that area, I'll have a better picture of methods to go about it. |
|
| Back to top |
|
|
judecn
n00b
Joined: 07 Jan 2015
Posts: 17
|
| Posted: Mon Jan 12, 2015 8:46 am Post subject: |
|
|
| Quote: | | So if it's a focus of your design, as it appears to be from your site, with respect I think you're getting caught up in the hype. |
| Quote: | | This is nothing new, and simply an application of whatever userland agent is listening to netlink. |
| Quote: | | I don't really see why you would need to have vdev like as the device manager and a cop at the same time. |
| Quote: | | My main point was in fact that "equivocating" process' access to device nodes, as you put it, is a dead-end, since that is the kernel's job. And you're still going on about it, as if I never said that at all, and as if it is the correct thing to do. It is not. |
(Addressing all of the above at once).
The focus of the design is to handle situations where the decision to allow program X to access device node /dev/Y is predicated on information that is not available to the kernel. That is, I need to enforce a system-wide invariant that states that for each program X and device node Y, there is an *arbitrary* predicate P such that X can access Y if and only if P is true. Moreover, I need to enforce this invariant in a portable manner (precluding netlink) and in a way that is backwards-compatible with existing programs (precluding rewriting them to use something like ConsoleKit).
While preserving this invariant with existing mechanisms is possible today, doing so is tedious in practice since this invariant is implicit--it's encoded in the steps the mechanisms take in reaction to events that alter the truth of the predicate for one or more programs or device files. For example, the mechanism "when Jude logs in on tty1, chown /dev/tty1 to jude.jude, and when he logs out, chown it back to root.root" implicitly encodes the invariant "any program running with Jude's UID or GID may read and write /dev/tty1 if and only if Jude is logged in". As far as I know, there isn't a way to define and enforce these invariants explicitly. It would be good to have one, however, since there are cases where the correctness of the invariant is more important than the steps taken to enforce it (but obviously both are important), and sometimes, defining the invariant's predicate is simpler than defining all the possible steps to take to enforce it.
Vdev solves this problem. With vdev, the admin defines P explicitly for a set of X and a set of /dev/Y (this information is encoded as a vdev ACL). The predicate P is defined as a set of process-matching criteria, one of which is allowed to be an arbitrary program (allowing for arbitrary predicates). The invariant is enforced by evaluating P to determine whether or not vdev shows a requesting process a particular device file. Vdev's approach to access control is the dual form of the approaches of existing mechanisms--it's no more or less powerful; it's just a different way of expressing device file access control.
To show that this isn't about following the multi-seat hype (and I'm a bit surprised it is thought of as "hype," since there are proven large-scale deployments in use today), here are two real-world access control scenarios from $DAYJOB and personal life that are somewhat tedious and difficult (but not impossible) to address with existing mechanisms, but somewhat easier to address with vdev's approach.
Example 1: I'd like to run some interactive applications in containers (i.e. a web browser, unetbootin, a build process, etc.), and they sometimes need to access a subset of hot-pluggable devices. However, I do not trust them enough to let them see all device files, since revealing even the *existence* of a device file can leak sensitive information. This precludes bind-mounting /dev into the container, so some other agent needs to place the right device nodes into the right containers. However, some of these programs also expect to be able to detect when a device gets added or removed, so I can't just make a static /dev a priori for each container--some agent (me or a program) needs to mknod() the device files when the device shows up.
With existing mechanisms, I have two options. On the one hand, I need to create each device file whenever I plug something in and unlink it once I unplug it, so the contained processes can act on it (I find this prospect tedious and annoying, but that's just me). On the other hand, I can have some agent do it for me automatically, according to some pre-defined policy (i.e. udev rules, mdev scripts) that ensures that only the whitelisted devices appear in the container. However, I would need to re-address this problem for each OS I use, since AFAIK there are no portable agents. The policy logic would be portable, but the interface to the agent would not be. Also, the policy logic itself would be somewhat fragile without careful engineering, since I may not always use the same directory for a container's root, and I may run multiple instances of the same container at the same time with different root directories.
With vdev, I need to create a small script for vdev to use to check whether or not a given PID lives in a given container, and write one ACL per container type that specifies a whitelist of that container's device nodes predicated on whether or not the requesting process belongs to that container (which vdev determines by running said small script). Then, I can bind-mount /dev into each container whenever I spin it up, and hotplugged devices show up and disappear in the right containers as expected. I don't have to think about what happens when the container uses an arbitrary directory for its root, nor do I have to think about what happens when I run multiple instances of the same container. Regarding portability, the only thing that would need to be ported to each new OS (besides vdev; this is speaking from a vdev user's perspective) would be that small script, and OSs that support containers usually have some notion of doing this already built-in (so this is expected to be easy).
Example 2: Many users have an account on the same machine, but at most one person can log in locally. Any of them can ssh in remotely. If a user is logged in locally, the other users *cannot* be allowed to access the input devices, video devices, or removable storage devices, since the local user must have exclusive read/write access for security purposes (moreover, any programs that have opened these files must be terminated before the local user logs in). Also, remote users should not be allowed to learn information that would allow them to infer what the local user is doing--for example, they should not even see the appearance of a device file corresponding to a removable drive. At the same time, this restriction should only apply while someone is logged in locally--for example, barring a local login, remote users should be able to use the GPU for OpenCL programs, and access hardware sensors (i.e. the webcams, the microphone, the ambient temperature, etc.) to check up on the room the computer resides in (but these should be locked out when someone has logged in locally, for privacy).
With existing mechanisms, I need to create a login script that chown's/chmod's the relevant device files on local login to the logged in user, and terminates all processes that have open file descriptors to them. To hide the local user's behavior from the ssh'ed users, I'll also need to ensure that each local device appears under a directory in /dev that is only searchable by the local user, and configure the device manager to place device files for hotpluggable devices in that directory.
With vdev, I need to write an ACL that filters the privileged device files predicated on whether or not there's someone logged in locally. This is readily achieved by making a small script to see if there exists a user that has an X server running as a child of the display manager (if logging in via a display manager), or owns a tty (if logging in textually).
| Quote: | For anyone who's considering programming, I sincerely hope it doesn't take you that long to let go of your ego in respect of your code.
Just bear in mind: the second system effect means that you should plan to throw two away. |
I consider the *Kits to be the proverbial "first system/prototype" and systemd to be the proverbial "second system," and I'm doing my best to learn from both so I don't repeat their mistakes. I'm also doing my best to learn from the systemd development methodology: you'll never see met foist any of my more controversial design decisions on users (turning them off or compiling them out will be supported), you'll never see me eschew portability, and you'll never see me tightly couple my projects together unless there is sufficient technical merit (and even then, I'd continue to support the option of using them separately indefinitely).
Also, I realize that some users don't want or like vdev's approach to access control, and that's perfectly fine by me. I'm supporting the ability to compile it out for users who would otherwise find it useful (in which case, it would behave like a lite version of udev). As mentioned earlier in this thread, other behaviors (like mdev-like behavior) will be supported as well. I'm not so egotistical to think that there is One True Way of doing things, or that I know what it is 
| Quote: | | ... would it be better to get the admin to whitelist binaries rather than trying to blacklist based on a hash which could be changed? |
Yes; my example you quoted wasn't that good in retrospect. But, either blacklisting or whitelisting can be achieved, depending on the ACL's predicate. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 646
|
| Posted: Mon Jan 12, 2015 8:06 pm Post subject: |
|
|
| judecn wrote: |
I consider the *Kits to be the proverbial "first system/prototype" and systemd to be the proverbial "second system," and I'm doing my best to learn from both so I don't repeat their mistakes. I'm also doing my best to learn from the systemd development methodology: you'll never see met foist any of my more controversial design decisions on users (turning them off or compiling them out will be supported), you'll never see me eschew portability, and you'll never see me tightly couple my projects together unless there is sufficient technical merit (and even then, I'd continue to support the option of using them separately indefinitely).
Also, I realize that some users don't want or like vdev's approach to access control, and that's perfectly fine by me. I'm supporting the ability to compile it out for users who would otherwise find it useful (in which case, it would behave like a lite version of udev). As mentioned earlier in this thread, other behaviors (like mdev-like behavior) will be supported as well. I'm not so egotistical to think that there is One True Way of doing things, or that I know what it is |
I see the *kits as a security nightmare waiting to happen (and the way systemd ties everything together, something that will make Windows' flaws look minimal in comparison)... So, personally, even if a sane default is shipped (even if that sane default is to allow nothing), I have no interest in it. With that in mind, I'm glad to hear that it will be possible to configure it out of even being built.
I have no problem with such a project existing, it's just functionality that I think is too hard to get right and WAY too easy to get abused. |
|
| Back to top |
|
|
v_andal
Guru
Joined: 26 Aug 2008
Posts: 541
Location: Germany
|
| Posted: Tue Jan 13, 2015 7:45 am Post subject: |
|
|
| Quote: | | Also, remote users should not be allowed to learn information that would allow them to infer what the local user is doing--for example, they should not even see the appearance of a device file corresponding to a removable drive. |
Well, what if the user wants remote users to see the device he/she has pluged-in? I don't work on "multi-seat" computers, but few times already I've had to login to my home computer remotely and to ask my wife to plug-in some USB stick with data that I needed. If the system automatically hides it, then there must be some simple and obvious way for the user to disable this hiding.
Don't you have a feeling, that you are trying to "suit'em all"? There are different usage scenarios and there should be tools appropriate for each scenario, not single tool trying to serve any possible way. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 13, 2015 1:11 pm Post subject: |
|
|
I agree it looks bad ; limiting how many connection a user could do on your host is not a task for a /dev manager. If i open a console and my keyboard for whatever reason disconnect, your system will prevent me from login with ssh to restart/reenable a keyboard your manager hide to me (because my other console is still running).
You were thinking it could be nice security addition, while i see the point, if one user have all hardware access, another same user log inside an ssh might be some jerk and we disable access to hardware for him.
But it is not something for a dev manager. If i agree two "krinn" are on my computer i don't see why vdev assume one krinn is fine and the second is an evil abuser. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Tue Jan 13, 2015 1:35 pm Post subject: |
|
|
| v_andal wrote: |
Well, what if the user wants remote users to see the device he/she has pluged-in? I don't work on "multi-seat" computers, but few times already I've had to login to my home computer remotely and to ask my wife to plug-in some USB stick with data that I needed. If the system automatically hides it, then there must be some simple and obvious way for the user to disable this hiding.
Don't you have a feeling, that you are trying to "suit'em all"? There are different usage scenarios and there should be tools appropriate for each scenario, not single tool trying to serve any possible way. |
Here's the issue.
We're now talking policy. Some people don't want "multi-seat" computers - but some do. You reference trying to gain remote access to your computer and having your wife plug in a USB stick. You're right, in that this is a situation where you need and should have access, and a "tight console-based policy" would prevent it. The key is that you're talking a home machine. For that matter, on my wife's machine I often open an xterm and "su - <myself>" to do things on it, and the *kit policies are a pain in the neck for that. It's a blasted home machine. On the other hand, for a university machine a "tight console-based policy" is probably quite correct.
The issue is that policy should not be encased in code. Code should enable policy, but the policies themselves should be configured. Ideally the code should ship with several sample policies, explaining how to select the appropriate one for the usage model of that computer. Linus has always been quite adamant about not putting policy into the kernel, but there certainly are policy mechanisms in there.
The worst thing about systemd is that it enshrines policy, if not into code, then so deeply into obscure configuration that no user will ever touch it. That is, the worst thing about systemd besides its Borg nature, and the worst thing besides it's probably security exposures, etc, etc, etc.
Make policy configurable. Better yet, ship several sample policy configurations.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Jan 13, 2015 6:25 pm Post subject: |
|
|
| depontius wrote: | | Make policy configurable. Better yet, ship several sample policy configurations. |
..and you end up with PAM. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Tue Jan 13, 2015 6:34 pm Post subject: |
|
|
"multi-seat" is RedHat's preferred euphemism for "mainframe with dumb clients".
It might be a better use of effort to concentrate on building a stable foundation for the other 99.9% of Linux - those with one or less "seats", who aren't already vendor-locked into corporate support contracts. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Tue Jan 13, 2015 6:38 pm Post subject: |
|
|
| steveL wrote: | | depontius wrote: | | Make policy configurable. Better yet, ship several sample policy configurations. |
..and you end up with PAM. |
I know some people struggle as hard to remove PAM as they do *kit. So far I've not been one of them, and I've done some PAM configuration myself. Nor does PAM really ship sample policies - they ship sample configurations, and that's something different.
Typically distributions end up developing the default policy and the configuration to implement that policy. That's usually OK, and I change it as needed. (I just wish etc-update wouldn't try to change my "PermitRootLogin" back to "Yes" every blasted time OpenSSH got updated.) I will add the the *kit policies/configurations are obfuscated almost to the point of being unchangable, and that's from someone who added modelines to xf86config, back in the day.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
judecn
n00b
Joined: 07 Jan 2015
Posts: 17
|
| Posted: Tue Jan 13, 2015 8:20 pm Post subject: |
|
|
| Quote: | | Well, what if the user wants remote users to see the device he/she has pluged-in? I don't work on "multi-seat" computers, but few times already I've had to login to my home computer remotely and to ask my wife to plug-in some USB stick with data that I needed. If the system automatically hides it, then there must be some simple and obvious way for the user to disable this hiding. |
| Quote: | | The issue is that policy should not be encased in code. Code should enable policy, but the policies themselves should be configured. Ideally the code should ship with several sample policies, explaining how to select the appropriate one for the usage model of that computer. |
| Quote: | | Make policy configurable. Better yet, ship several sample policy configurations. |
Vdev's code only gives you a mechanism to enforce parameterizations of the invariant I described above. The user must specify the parameters of the invariant (X, Y, and P) to create policies. In my examples above, I showed how to get vdev to enforce two particular policies by giving two sets of values for X, Y, and P, but obviously you can specify different values to get whatever policies you want 
When it ships, vdev will come with some example ACLs that show how to set X, Y, and P (this is in addition to formal documentation and a wiki). However, I should emphasize that policy is completely separate from code. The vdev ACLs are currently implemented as ini-formatted files that get loaded when it starts (there is also a plan to present the ACLs as an API filesystem within vdev--for example, rooted at /dev/vdev/acls/--that will let the user change them at runtime). There aren't any ACLs installed or enabled by default. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Jan 13, 2015 10:14 pm Post subject: |
|
|
| judecn wrote: | The focus of the design is to handle situations where the decision to allow program X to access device node /dev/Y is predicated on information that is not available to the kernel.
That is, I need to enforce a system-wide invariant that states that for each program X and device node Y, there is an *arbitrary* predicate P such that X can access Y if and only if P is true. |
Firstly separate out the decision making part, and use PAM for that, as well as group membership.
| Quote: | | Moreover, I need to enforce this invariant in a portable manner (precluding netlink) and in a way that is backwards-compatible with existing programs (precluding rewriting them to use something like ConsoleKit). |
WTF is portable about udev? And why does it need to be portable in the sense of providing the same API everywhere? That's the job of an OS-abstraction layer, not the job of an OS-specific device-node manager.
| Quote: | | While preserving this invariant with existing mechanisms is possible today, doing so is tedious in practice since this invariant is implicit--it's encoded in the steps the mechanisms take in reaction to events that alter the truth of the predicate for one or more programs or device files. |
I must demur from your use of the term "invariant" which sounds good, but is incredibly sloppy imo. There is nothing invariant about "an*arbitrary* predicate" evaluated at runtime.
| Quote: | | For example, the mechanism "when Jude logs in on tty1, chown /dev/tty1 to jude.jude, and when he logs out, chown it back to root.root" implicitly encodes the invariant "any program running with Jude's UID or GID may read and write /dev/tty1 if and only if Jude is logged in". As far as I know, there isn't a way to define and enforce these invariants explicitly. |
*sigh* We've had this conversation a couple of times, in one of the umpteen threads about this borkage of a design. Firstly POSIX has interfaces for this already since the late 90s, and so does PAM. You leave the decision making to PAM, which is very simple, unless you're configured to compile without support for it.
| Quote: | | To show that this isn't about following the multi-seat hype (and I'm a bit surprised it is thought of as "hype," since there are proven large-scale deployments in use today) |
You're conflating LTSP type deployments, with device-node marking, as if hype about the second necessarily implies hype about the former; then criticising me for using the term hype about the second, and acting as if I'm suddenly some sort of luddite. Don't do that.
| Quote: | | I'd like to run some interactive applications in containers (i.e. a web browser, unetbootin, a build process, etc.), and they sometimes need to access a subset of hot-pluggable devices. However, I do not trust them enough to let them see all device files, since revealing even the *existence* of a device file can leak sensitive information. This precludes bind-mounting /dev into the container, so some other agent needs to place the right device nodes into the right containers. |
But it doesn't preclude bind-mounting the specific nodes you want to expose.
| Quote: | | However, some of these programs also expect to be able to detect when a device gets added or removed, so I can't just make a static /dev a priori for each container--some agent (me or a program) needs to mknod() the device files when the device shows up. |
Both this comment and the former act as if the need for a userland device-manager wasn't identified years ago. That's where the impetus for udev came from. The trouble is the direction it's taken, in conjunction with other badly-conceived lunacy from the freedesktop clique.
IOW I don't see why you feel the need to outline the case for such a userland mechanism at such length, as it's a natural extension of device-notifier chains in the kernel, and everyone was happy for exactly these issues to be addressed by it.
It certainly doesn't justify anything you're arguing for; it's merely existing ground. You appear to be using pre-existing discussion from several years ago as lending authority to what you're discussing now, which are bad ideas as has been discussed here and on the kernel ml.
| Quote: | | Many users have an account on the same machine, but at most one person can log in locally. Any of them can ssh in remotely. If a user is logged in locally, the other users *cannot* be allowed to access the input devices, video devices, or removable storage devices, since the local user must have exclusive read/write access for security purposes (moreover, any programs that have opened these files must be terminated before the local user logs in). Also, remote users should not be allowed to learn information that would allow them to infer what the local user is doing--for example, they should not even see the appearance of a device file corresponding to a removable drive. At the same time, this restriction should only apply while someone is logged in locally--for example, barring a local login, remote users should be able to use the GPU for OpenCL programs, and access hardware sensors (i.e. the webcams, the microphone, the ambient temperature, etc.) to check up on the room the computer resides in (but these should be locked out when someone has logged in locally, for privacy). |
That makes no sense at all to me. "You can use my webcam to spy on me so long as I haven't logged in, or if I log out, or you manage to log me out via one of the many attack surfaces we've been busily adding."
Again this was discussed in earlier threads. The video of the German net-admin discussing trying to make nubkit work over a period of years in an organisation: y'know the people that supposed USP was supposed to help, shows the issues. Kernel-discussion about how it breaks the underlying model only adds to the no-no.
| Quote: | | I consider the *Kits to be the proverbial "first system/prototype" and systemd to be the proverbial "second system," |
Oh dear, no. You haven't understood what I meant at all. Do you really believe hal for example, wasn't already a second system when it was pushed too early, in 0.x stage? You must have seen the modern trend toward TDD which is basically reiterating the methodology people have been using for decades. People have been planning "to throw one away" for decades, and the problem is that means they're foisting their second-systems on us instead. After all, someone else can patch it up later, right?
Both of those are just dead-ends, stages in the ego-struggle of Poeterring, as he keeps stubbornly pursuing the inturgrated One True Way and the delusion of control.
| Quote: | | I'm doing my best to learn from both so I don't repeat their mistakes. |
The problem is so much of what they're doing is totally unnecessary. There's only so many ways to analyse a turd: the problem is when they're so complex, it's easy to lose track of the faulty premises, inculcated by lazy thinking and lack of research. Especially when any discussion of flaws provokes a defensive (sometimes passive-)aggressive reaction, instead of a transparent, focussed discussion.
| Quote: | | I'm also doing my best to learn from the systemd development methodology: you'll never see met foist any of my more controversial design decisions on users (turning them off or compiling them out will be supported), you'll never see me eschew portability |
Glad to hear it.
| Quote: | | and you'll never see me tightly couple my projects together unless there is sufficient technical merit (and even then, I'd continue to support the option of using them separately indefinitely). |
In which case they're not tightly-coupled. I can't see any sufficient technical merit to tightly-couple separate projects together, apart from splitting out a sub-project. Which is not the same thing at all.
It's ok to be coupled to a lower-layer, though you really want to insulate yourself from that in the general case, but as soon as you have inverted coupling, you're fscked.
| Quote: | | ... would it be better to get the admin to whitelist binaries rather than trying to blacklist based on a hash which could be changed? |
| Quote: | | Yes; my example you quoted wasn't that good in retrospect. But, either blacklisting or whitelisting can be achieved, depending on the ACL's predicate. |
Why not just tie into things like AIDE instead of reinventing the wheel? If the user has it then they're taking it seriously; if not then don't provide a false lullaby. Down that route lies importing unreviewed crypto from my brother, as nepotism trumps technical merit in the Brave Nub World-2.0.. ;)
| Quote: | | Also, I realize that some users don't want or like vdev's approach to access control, and that's perfectly fine by me. I'm supporting the ability to compile it out for users who would otherwise find it useful (in which case, it would behave like a lite version of udev). As mentioned earlier in this thread, other behaviors (like mdev-like behavior) will be supported as well. I'm not so egotistical to think that there is One True Way of doing things, or that I know what it is ;) |
Great; I wasn't trying to say anything about you, as mentioned. I look forward to seeing what portable code you come out with :-)
And welcome to the Gentoo community. |
|
| Back to top |
|
|
v_andal
Guru
Joined: 26 Aug 2008
Posts: 541
Location: Germany
|
| Posted: Wed Jan 14, 2015 8:03 am Post subject: |
|
|
| depontius wrote: |
We're now talking policy. Some people don't want "multi-seat" computers - but some do. |
Yes. That's life. And in this life, I can manage my home computer using udev. And I could manage it before without udev. So I really can't understand, why more and more programs are forced on my head  Why should I keep learning new stuff, when old was working for me?
Writing policies seems like nice idea, but udev also offers ability to write rules, PAM allows that too. How many people actually do use that? Most just complain, that it is hard. It's also life. I don't doubt that people shall also complain about policies in vdev. At the end of the day, everything is decided by the applications that people use. If those applications are tied to systemd, they will be stuck with systemd, no difference how good or bad it is.
Somehow I believe, that now we don't need new program allowing all kinds of rules. We need clear definition of small set of rules that the system must follow and the rest is up to the users ambition. Those "multi-seat" normally always have dedicated sysadmin and he/she is sometimes even paid for configuring the system. All is needed, is set of rules that would allow such configuration. After all, they can simply lock all (remote) users into virtual environment providing to it only allowed set of information.
Oh well, all of it is really nothing more than grunting We have system assembled from pieces created by magnitude of people. It is very improbable, that such system would follow rules.  |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Jan 14, 2015 5:39 pm Post subject: |
|
|
| depontius wrote: | | We're now talking policy. Some people don't want "multi-seat" computers - but some do. |
| v_andal wrote: | | Yes. That's life. And in this life, I can manage my home computer using udev. And I could manage it before without udev. So I really can't understand, why more and more programs are forced on my head :D Why should I keep learning new stuff, when old was working for me? |
Agreed 100%, in the sense that: you don't build complex things by making previously simple cases, complex. That's just bad thinking.
| Quote: | | All is needed, is set of rules that would allow such configuration. |
You've hit the nail on the head: policy is configuration.
That's the whole point of config files: to allow the admin or end-user to change the defaults. As with programming, so with use: it's best to keep that simple plain-text so that policy can be reviewed and edited easily. In a word, "maintenance". |
|
| Back to top |
|
|
judecn
n00b
Joined: 07 Jan 2015
Posts: 17
|
| Posted: Wed Jan 14, 2015 7:49 pm Post subject: |
|
|
Hi steveL,
I considered PAM before creating vdev. The reason I'm not using it is because it doesn't solve the problem adequately. PAM concerns itself with supporting multiple arbitrary ways to authenticate PAM-aware programs. Recall that I need a way to authenticate arbitrary processes without modifying them.
I could achieve my goals with some combination of PAM and existing tools (i.e. udev rules/mdev scripts) on a case-by-case basis, but I would be solving different instances of the same problem over and over again. vdev saves me the effort, and by simplifying the problem domain to only three parameters (X, Y, and P), it makes it much easier to reason about device file access control than trying to consider the (fundamentally undecidable) side-effects of combining existing tools in different ways to address each specific (X, Y, P) tuple.
I think our difference in opinions stem from my desire to do only what it necessary to enforce a certain class of access control policies, whereas you think that because what we have now is sufficient, no further work is needed in this space. However, I think we both agree that parsimony is an important principle to stick with in system design. What I have argued in my earlier posts is that there are very real cases where the difference between doing only what is necessary (i.e. hiding or unhiding a device node from a process based on some runtime-evaluated predicate) versus using any/all existing tools to build a sufficient solution is so large that I either end up creating something that's a vdev work-alike, or I end up having to solve different instances of the same problem from scratch. Thus, I currently believe vdev is the more parsimonious solution (but I could be convinced otherwise, if for example there already is a work-alike somewhere that I don't know about).
| Quote: | | WTF is portable about udev? And why does it need to be portable in the sense of providing the same API everywhere? That's the job of an OS-abstraction layer, not the job of an OS-specific device-node manager. |
Udev is not portable, and I consider this to be a limitation. Device file management is a solved problem, but every UNIX solves it differently without offering any fundamental improvements. This annoys me, since I use three different UNICES and would prefer to not have to figure out how to write the same device management rule three different ways.
You seem to be suggesting that it would be better to port the netlink socket class to each UNIX's OS abstraction layer. If so, this is overkill. The fact that udev uses netlink is an implementation detail that does not affect how it interfaces with other programs. Making vdev portable is just a matter of writing the appropriate OS-specific back-end "driver" that translates OS-specific device notifications into data structures that the rest of vdev understands.
| Quote: | | There is nothing invariant about "an*arbitrary* predicate" evaluated at runtime. |
Can I have vdev execute "sh -c dd if=/dev/urandom of=/dev/sda bs=1M" as part of its predicate? Sure. Will I actually do so? No. Will I include something like "For best results, ensure that your predicates have no externally-visible side-effects when evaluated and are guaranteed to run to completion" in the documentation? I guess I'll have to.
| Quote: | | You're conflating LTSP type deployments, with device-node marking, as if hype about the second necessarily implies hype about the former; then criticising me for using the term hype about the second, and acting as if I'm suddenly some sort of luddite. Don't do that. |
You're not a luddite, and I never said or even thought you were. I was pointing out that I find it odd to characterize a widely-used and proven computer multiplexing mechanism as hype, since "hype" implies that lots of people are excited about it, but no one is using it for anything serious. I understand that the greater Linux community is perhaps more excited about it than it needs to be, but the real-world cases I was thinking of are the large-scale multi-seat deployments in Brazil and Macedonia, used for giving school children access to computers.
| Quote: | | But it doesn't preclude bind-mounting the specific nodes you want to expose. |
Maybe you meant "symlink" or "hardlink", since I'm pretty sure you can't bind-mount a file . Besides, it doesn't solve the problem of having the device nodes appear in each container's /dev without necessarily coupling the policy logic in the udev rules/mdev scripts to my container policies. At least with vdev's approach, the coupling between device node management policy and container setup policy is necessarily factored out into a predicate. With udev/mdev, I would instead need to create an "inner platform" for them to act on container policies without hard-wiring their behaviors.
| Quote: | Both this comment and the former act as if the need for a userland device-manager wasn't identified years ago. That's where the impetus for udev came from. The trouble is the direction it's taken, in conjunction with other badly-conceived lunacy from the freedesktop clique.
IOW I don't see why you feel the need to outline the case for such a userland mechanism at such length, as it's a natural extension of device-notifier chains in the kernel, and everyone was happy for exactly these issues to be addressed by it.
It certainly doesn't justify anything you're arguing for; it's merely existing ground. You appear to be using pre-existing discussion from several years ago as lending authority to what you're discussing now, which are bad ideas as has been discussed here and on the kernel ml. |
That's because that's *not* what I'm arguing for. What I am arguing is that there is a general formulation of the problems I'm trying to solve, and by designing vdev to reduce each instance of the problem to a few parameters, I can solve each instance of the problem and reason about its correctness much more readily than creating one-off point solutions to each instance.
| Quote: | | That makes no sense at all to me. "You can use my webcam to spy on me so long as I haven't logged in, or if I log out, or you manage to log me out via one of the many attack surfaces we've been busily adding." |
More like, "When no one is using my home computer, I want to use its webcam to watch the door to my house" or "When no one is using my office computer between these hours at night, I want to watch and listen for intruders" or "When no one is using my office computer at all, I want to run OpenCL workloads on its GPU."
| Quote: | | Oh dear, no. You haven't understood what I meant at all. Do you really believe hal for example, wasn't already a second system when it was pushed too early, in 0.x stage? You must have seen the modern trend toward TDD which is basically reiterating the methodology people have been using for decades. People have been planning "to throw one away" for decades, and the problem is that means they're foisting their second-systems on us instead. After all, someone else can patch it up later, right? |
What does TDD have to do with hal, and what does hal have to do with vdev? hal operates in a different problem domain than vdev, and vdev's scope is a *lot* smaller.
Also, say what you want about Lennart Poetterring's development methodologies and attitudes, but he's not the principle author of the *Kits, nor did he create hal or udev. Not sure why you think they're "stages in the ego-struggle of Poeterring" when at best he was the last maintainer of ConsoleKit and sent a few patches to it along the way.
| Quote: | | The problem is so much of what they're doing is totally unnecessary. |
Agreed. They failed in part because they didn't understand the problem(s) they were trying to solve well enough, and in part because they had a tendancy to over-engineer their solutions (making them inflexible).
| Quote: | | Why not just tie into things like AIDE instead of reinventing the wheel? If the user has it then they're taking it seriously; if not then don't provide a false lullaby. Down that route lies importing unreviewed crypto from my brother, as nepotism trumps technical merit in the Brave Nub World-2.0.. |
Because the problem you're referring to is not related to intrusion detection; it's related to identifying a particular process that's attempting to access a device file.
| Quote: | | And welcome to the Gentoo community. |
Glad to be here . Everyone's feedback has been great!
-Jude
Last edited by judecn on Sat Jan 17, 2015 12:14 am; edited 4 times in total |
|
| Back to top |
|
|
judecn
n00b
Joined: 07 Jan 2015
Posts: 17
|
| Posted: Thu Jan 15, 2015 9:22 am Post subject: |
|
|
Also, I just thought I'd let everyone know that I just pushed code that makes it possible to compile out the equivocating filesystem and ACL parts of vdev, and removes the dependency on OpenSSL. When you compile it with default flags, you'll get a "udev-lite"--just a daemon that manages your device files. Now to see about removing all C++-isms...
Last edited by judecn on Fri Jan 16, 2015 12:41 am; edited 2 times in total |
|
| Back to top |
|
|
bstaletic
Apprentice
Joined: 05 Apr 2014
Posts: 253
|
| Posted: Thu Jan 15, 2015 11:55 am Post subject: |
|
|
| Looking forward to a clean version of vdev. When it comes out I'll probably try it out, andif I like it I'll put it in AUR. |
|
| Back to top |
|
|
judecn
n00b
Joined: 07 Jan 2015
Posts: 17
|
| Posted: Sun Jan 18, 2015 11:27 pm Post subject: |
|
|
| Another update: as of commit 17a5c90c39d91b3963314469108f9cf444c2fc6d, vdev no longer needs C++ containers. It compiles with gcc, and links only against libraries in /lib. |
|
| Back to top |
|
|
mayak
n00b
Joined: 16 Jul 2013
Posts: 26
|
| Posted: Mon Jan 19, 2015 8:14 am Post subject: |
|
|
| judecn wrote: | | Another update: as of commit 17a5c90c39d91b3963314469108f9cf444c2fc6d, vdev no longer needs C++ containers. It compiles with gcc, and links only against libraries in /lib. |
Great news! Although I am not an user yet, thank you very much for creating and working on an alternative. Looking forward to the next updates. |
|
| Back to top |
|
|
zoulou99
n00b
Joined: 15 Jan 2015
Posts: 16
|
| Posted: Fri Feb 20, 2015 2:34 pm Post subject: |
|
|
| judecn wrote: | | vdev no longer needs C++ containers. It compiles with gcc, and links only against libraries in /lib. |
thank you very much.
_________________
mydigitallife |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
