Re: [PATCH v2 0/2] unprivileged fanotify listener

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon 22-03-21 20:38:32, Amir Goldstein wrote:
> > > > The problem here is that even if unprivileged users cannot compromise
> > > > security, they can still cause significant CPU overhead either queueing
> > > > events or filtering events and that is something I haven't been able to
> > > > figure out a way to escape from.
> > >
> > > WRT queueing overhead, given a user can place ~1M of directory watches, he
> > > can cause noticable total overhead for queueing events anyway. Furthermore
> >
> > I suppose so. But a user placing 1M dir watches at least adds this overhead
> > knowingly. Adding a overhead on the entire filesystem when just wanting to
> > watch a small subtree doesn't sound ideal. Especially in very nested setups.
> > So yes, we need to be careful.
> >
> 
> I was thinking about this some more and I think the answer is in your example.
> User can only place 1M dir watches if ucount marks limits permits it.
> 
> So whatever we allow to do with subtree or userns filtered marks should
> also be limited by ucounts.

Yes, agreed.

> > > the queue size is limited so unless the user spends time consuming events
> > > as well, the load won't last long. But I agree we need to be careful not to
> > > introduce too big latencies to operations generating events. So I think if
> > > we could quickly detect whether a generated event has a good chance of
> > > being relevant for some subtree watch of a group and queue it in that case
> > > and worry about permission checks only once events are received and thus
> > > receiver pays the cost of expensive checks, that might be fine as well.
> > >
> >
> > So far the only idea I had for "quickly detect" which I cannot find flaws in
> > is to filter by mnt_userms, but its power is limited.
> 
> So I have implemented this idea on fanotify_userns branch and the cost
> per "filtered" sb mark is quite low - its a pretty cheap check in
> send_to_group()
> But still, if an unbound number of users can add to the sb mark list it is
> not going to end well.

Thinking out loud: So what is the cost going to be for the side generating
events? Ideally it would of O(number of fanotify groups receiving event).
We cannot get better than that and if the constants aren't too big I think
this is acceptable overhead. Sure this can mean total work of (number of
users) * (max number of subtree marks per user) for queueing notification
event but I don't think it is practical for a DoS attack and I also don't
think that in practice users will be watching overlapping subtrees that
much.

The question is whether we can get that fast. Probably not because that
would have to attach subtree watches to directory inodes or otherwise
filter out unrelated fanotify groups in O(1). But the complexity of
O(number of groups receiving events + depth of dir where event is happening)
is probably achievable - we'd walk the tree up and have roots of watched
subtrees marked. What do you think?

Also there is a somewhat related question what is the semantics of subtree
watches in presence of mounts - do subtree watches "see through" mount
points? Probably not but then with bind mounts this can be sometimes
inconvenient / confusing - e.g. if I have /tmp bind-mounted to /var/tmp and
I'm watching subtree of /var, I would not get events for what's in
/var/tmp... Which is logical if you spell it out like this but applications
often don't care how the mount hierarchy looks like, they just care about
locally visible directory structure.

> <hand waving>
> I think what we need here (thinking out loud) is to account the sb marks
> to the user that mounted the filesystem or to the user mapped to admin using
> idmapped mount, maybe to both(?), probably using a separate ucount entry
> (e.g. max_fanotify_filesystem_marks).

I'm somewhat lost here. Are these two users different? We have /home/foo
which is a mounted filesystem. AFAIU it will be mounted in a special user
namespace for user 'foo' - let's call is 'foo-ns'. /home/foo has idmapping
attached so system [ug]ids and non-trivially mapped to on-disk [ug]ids. Now
we have a user - let's call it 'foo-usr' that has enough capabilities
(whatever they are) in 'foo-ns' to place fanotify subtree marks in
/home/foo. So these marks are naturally accounted towards 'foo-usr'. To
whom else you'd like to also account these marks and why?

> We can set this limit by default to a small number (128?) to limit the sb list
> iteration per filesystem event and container manager / systemd can further
> limit this resource when creating idmapped mounts, which would otherwise
> allow the mapped user to add "filtered" (*) sb marks.
> </hand waving>
>
> (*) "filtered" can refer to both the userns filter I proposed and going forward
>      also maybe to subtree filter

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux