Will Young wrote: > Darren Reed wrote: >> Will Young wrote: >> >>> Based on the description of the desired granularity I think the >>> typical model of using PRIV_SYS_NET_CONFIG (and/or >>> PRIV_SYS_IP_CONFIG) then modifying commands such as ipf to check >>> more specific authorizations works. >>> >> >> I must confess that I'm feeling quite alarmed at how many different >> actions are falling under PRIV_SYS_NET_CONFIG. It's like >> anyone with that privilege is the "network superuser", which kind >> of scares me. Which is why I'm asking "where are privileges going?" >> Does that one privilege really need to be reused amongst so many >> different programs/features? >> > > While there is a general sentiment of the finer grain the better, I > think our first priority is the limiting running with any elevated > privileges. If this is done correctly there is no literal "network > superuser" in that users are given the privilege only when it is > constrained by specific commands which can enforce more complex rules > than the kernel privilege model.
You're assuming that the only way for something network related to happen is via a specific command. I'm assuming that one or more such commands have a bug (such as a buffer overflow or..) that allows for arbitrary execution of ioctls. So in that sense, I'm thinking that the right to execute any program to run with PRIV_SYS_NET_CONFIG is a right to execute any privilege that needs it. > Finer grain privileges would mean there is less to attack if one > escapes the constraints of specific commands, but this is of less > benefit then it sounds like unless the privileges are carefully > considered. I.e. a division by technologies gives a firewall > privilege, a tunnel privilege, an IPsec policy privilege, and an > interface change privilege that can each individually do different > forms of traffic redirection attacks. Yet a site may be inclined to > assign one of these privileges directly to a user as they sound much > safer. I'm not thinking of it just being "per-user", in the sense of the "user" being a person, but also "per-user" where the "user" is an application. For example, maybe someone is using squid in transparent proxy mode and rather than let that run as root (so it can talk to IPFilter), they'd rather use RBAC. Should we only offer PRIV_SYS_NET_CONFIG, here, or should we allow the administrator to choose something better? So while I am writing this, I've also pondered the question for an application like Punchin. What does it need to work? Or rather, what are the kernel interfaces that it needs to use that require privilege (or root) to function? I suppose what started this question/thread is that I haven't seen much ... advancement, yet, of privileges beyond the basic set that were delivered with FCS. So I'm wondering if the set of privileges we have is now "fixed" or if we're getting close to a point where it is suitable to review those that we have with a view to possibly expanding what's available or making some finer grained additions. As a networking guy, I'm feeling a bit disenfranchised with the state of privileges because we have so few networking ones compared to filesystem ;-( Darren
