On Tue, 2014-11-04 at 12:56 +0100, Jacek Bukarewicz wrote: > Hi, > > On 11/04/2014 10:56 AM, Patrick Ohly wrote: > > On Fri, 2014-10-31 at 19:17 +0100, Jacek Bukarewicz wrote: > >> It would be nice to get feedback from service developers whether you > >> find it useful and sufficient to secure your services. > >> Ideally, service developers could try this version of D-Bus and see if > >> they notice any problems. I'm not sure if other parts of security > >> infrastructure are ready so such tests can be performed though. > > It would be good if we could run dbus-monitor and Python scripts as if > > they were less-privileged apps. Does anyone know how to do that? > For testing purposes I ran python and dbus-send based scripts. With > standard settings - user is root, smack label is "User". > I believe that for Cynara it shouldn't be much difference between such > setup and for example user bob, app label "some_unprivileged_app", but > I'll check it too.
At least "my" D-Bus services run in the user session, so I would need to replicate a test setup with a normal user and an app running with neither "System" nor "User" label. > A simple way of making test environment closer to the actual is to > create proper smack rules (same as they are for User label) and switch > to unprivileged user (e.g. bob): > > echo "app_label System wx" > /sys/fs/smackfs/load2 > echo "app_label System::Shared rx" > /sys/fs/smackfs/load2 > echo "app_label System::Run rwxat" > /sys/fs/smackfs/load2 > echo "app_label System::Log rwxa" > /sys/fs/smackfs/load2 > echo "app_label User::Home rwxat" > /sys/fs/smackfs/load2 > echo "app_label User::App::Shared rwxat" > /sys/fs/smackfs/load2 > echo "app_label _ l" > /sys/fs/smackfs/load2 > echo "System app_label rwx" > /sys/fs/smackfs/load2 > (Setting up rules between "User" and "app_label" would also probably > be needed) Some authoritative answer on how to set up Smack rules would be useful. I don't know enough to get this right myself. > Then switch current process' smack label to "app_label" and switch to > user (e.g. bob) > echo "app_label" > /proc/self/attr/current > su bob > > > Also for test purposes I created python bindings for Cynara (admin and > client API) to easily set up policies and to invalidate policy when > required. > It's not production quality but it works for me. If anyone is interested > I can publish it on Cynara sandbox. That sounds useful. Without actual Cynara configs, all one could test is that illegal access gets denied. Examples for setting those up would also be useful. > > Needing one of several alternative privileges is already supported by > > writing different allow rules, one for each privilege. > > > Actually, I changed <check> rules so they behave like <allow> and <deny> > - the last rule that applies wins. I did it for several reasons: > - consistency with how policy matching currently behave > - Cynara is only consulted if the rule is the last applicable so no > redundant Cynara requests are needed (for example when <check> is within > <policy context="default" > section and <allow> is within <policy > user="root"> section (for example - check regular apps but allow > services running with root) > - it makes it possible to avoid redoing policy check if we already > have answer from Cynara (with previous approach we were never sure > whether it's the last applicable rule) I see. I can't think of reason why that shouldn't work. We just need to be very clear about what the semantic is. > Maybe I'm missing some required use cases that current approach > disallows (do we need alternative privileges?) so we'd have to switch > back to what you proposed, but honestly I'd prefer to stay like it is. I don't think we need alternative privileges, so I don't mind keeping it as you implemented it. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
