From: David Howells <firstname.lastname@example.org> To: Casey Schaufler <email@example.com>, Stephen Smalley <firstname.lastname@example.org> Cc: email@example.com, Andy Lutomirski <firstname.lastname@example.org>, Al Viro <email@example.com>, firstname.lastname@example.org, Linux FS Devel <email@example.com>, Linux API <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, LSM List <email@example.com>, LKML <firstname.lastname@example.org> Subject: Re: Rational model for UID based controls Date: Wed, 05 Jun 2019 22:06:03 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Casey Schaufler <email@example.com> wrote: > Right. You're mixing the kind of things that can generate events, > and that makes having a single policy difficult. Whilst that's true, the notifications are clearly marked as to type, so it should be possible to select different policies for different notification types. Question for you: what does the LSM *actually* need? There are a bunch of things available, some of which may be the same thing: (1) The creds of the process that created a watch_queue (ie. opened /dev/watch_queue). (2) The creds of the process that set a watch (ie. called sb_notify, KEYCTL_NOTIFY, ...); (3) The creds of the process that tripped the event (which might be the system). (4) The security attributes of the object on which the watch was set (uid, gid, mode, labels). (5) The security attributes of the object on which the event was tripped. (6) The security attributes of all the objects between the object in (5) and the object in (4), assuming we work from (5) towards (4) if the two aren't coincident (WATCH_INFO_RECURSIVE). At the moment, when post_one_notification() wants to write a notification into a queue, it calls security_post_notification() to ask if it should be allowed to do so. This is passed (1) and (3) above plus the notification record. The only problem I really have is that for a destruction message you want to get the creds of who did the last put on an object and caused it to be destroyed - I think everything else probably gets the right creds, even if they aren't even in the same namespaces (mount propagation, yuck). However, that one is a biggie because close()/exit() must propagate it to deferred-fput, which must propagate it to af_unix-cleanup, and thence back to deferred-fput and thence to implicit unmount (dissolve_on_fput()[*]). [*] Though it should be noted that if this happens, the subtree cannot be attached to the root of a namespace. > > In any case, that's what I was referring to when I said I might need to call > > inode_permission(). But UIDs don't exist for all filesystems, for example, > > and there are no UIDs on superblocks, mount objects or hardware events. > > If you open() or stat() a file on those filesystems the UID > used in the access control comes from somewhere. Setting a watch > on things with UIDs should use the access mode on the file, > just like any other filesystem operation. Another question for you: Do I need to let the LSM pass judgement on a watch that a process is trying to set? I think I probably do. This would require separate hooks for different object types: int security_watch_key(struct watch *watch, struct key *key); int security_watch_sb(struct watch *watch, struct path *path); int security_watch_mount(struct watch *watch, struct path *path); int security_watch_devices(struct watch *watch); so that the LSM can see the object the watch is being placed on (the last has a global queue, so there is no object). Further, do I need to put a "void *security" pointer in struct watch and indicate to the LSM the object bring watched? The watch could then be passed to security_post_notification() instead of the watch queue creds (which I could then dispense with). security_post_notification(const struct watch *watch, const struct cred *trigger_cred, struct watch_notification *n); Also, should I let the LSM audit/edit the filter set by IOC_WATCH_QUEUE_SET_FILTER? Userspace can't retrieve the filter, so the LSM could edit it to exclude certain things. That might be a bit too complicated, though. > Things like superblocks are sticker because we don't generally > think of them as objects. If you can do statfs(), you should be > able to set a watch on the filesystem metadata. > > How would you specify a watch for a hardware event? If you say > you have to open /dev/mumble to sent a watch for mumbles, you're > good there, too. That's not how that works at the moment. There's a global watch list for device events. I've repurposed it to carry any device's events - so it will carry blockdev events (I/O errors only at the moment) and usb events (add/remove device, add/remove bus, reset device at the moment). > > Now, I could see that you ignore UIDs on things like keys and > > hardware-triggered events, but how does this interact with things like mount > > watches that see directories that have UIDs? > > > > Are you advocating making it such that process B can only see events > > triggered by process A if they have the same UID, for example? > > It's always seemed arbitrary to me that you can't open your process up to > get signals from other users. What about putting mode bits on your ring > buffer? By default you could only accept your own events, but you could do a > rb_chmod(0222) and let all events through. Ummm... This mechanism is pretty much about events generated by others. Depend on what you mean by 'you' and 'your own events', it might be considered that you would know what events you were directly causing and wouldn't need a notification system for it. > Subject to LSM addition restrictions, of course. That would require the cred > of the process that triggered the event or a system cred for "hardware" > events. If you don't like mode bits you could use an ACL for fine > granularity or a single "let'em all in" bit for coarse. I'm not entirely sure how an ACL would help. If someone creates a watch queue, sets an ACL with only a "let everything in" ACE, we're back to the situation we're in now. As I understand it, the issue you have is stopping them getting events that they're willing to accept that you think they shouldn't be allowed. > I'm not against access, I'm against uncontrolled access in conflict with > basic system policy. David
next prev parent reply other threads:[~2019-06-05 21:06 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-04 16:34 [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] David Howells 2019-06-04 16:35 ` [PATCH 1/8] security: Override creds in __fput() with last fputter's creds " David Howells 2019-06-04 18:15 ` Andy Lutomirski 2019-06-04 16:35 ` [PATCH 2/8] General notification queue with user mmap()'able ring buffer " David Howells 2019-06-04 16:35 ` [PATCH 3/8] keys: Add a notification facility " David Howells 2019-06-04 16:35 ` [PATCH 4/8] vfs: Add a mount-notification " David Howells 2019-06-04 16:35 ` [PATCH 5/8] vfs: Add superblock notifications " David Howells 2019-06-04 16:36 ` [PATCH 6/8] fsinfo: Export superblock notification counter " David Howells 2019-06-04 16:36 ` [PATCH 7/8] block: Add block layer notifications " David Howells 2019-06-04 16:36 ` [PATCH 8/8] Add sample notification program " David Howells 2019-06-04 17:43 ` [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications " Andy Lutomirski 2019-06-04 20:31 ` Casey Schaufler 2019-06-04 21:05 ` Andy Lutomirski 2019-06-04 22:03 ` Casey Schaufler 2019-06-05 8:41 ` David Howells 2019-06-05 14:50 ` Casey Schaufler 2019-06-05 16:04 ` Andy Lutomirski 2019-06-05 17:01 ` Casey Schaufler 2019-06-05 17:47 ` Andy Lutomirski 2019-06-05 18:12 ` Casey Schaufler 2019-06-05 18:25 ` Stephen Smalley 2019-06-05 19:28 ` Greg KH 2019-06-05 21:01 ` Stephen Smalley 2019-06-05 16:56 ` Rational model for UID based controls David Howells 2019-06-05 17:40 ` Casey Schaufler 2019-06-05 21:06 ` David Howells [this message] 2019-06-05 17:21 ` [RFC][PATCH 0/8] Mount, FS, Block and Keyrings notifications [ver #2] David Howells 2019-06-04 20:39 ` David Howells 2019-06-04 20:57 ` Andy Lutomirski [not found] ` <CAB9W1A0AgMYOwGx9c-TmAt=1O6Bjsr2P3Nhd=2+QV39dgw0CrA@mail.gmail.com> 2019-06-05 4:19 ` Andy Lutomirski 2019-06-05 13:47 ` Stephen Smalley 2019-06-04 21:11 ` Casey Schaufler
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Rational model for UID based controls' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).