I am sorry for the short description of my problem. Here is a detailed description of what I wish to achieve so that you can help me better. I basically want that on the press of a button(or a command), the device switches to a mode in which certain services such as bluetooth, wi-fi, camera and/or gps be disabled (i.e. no application can access these services regardless of whether they were given these permissions on installation). The user should not be able to restart these services without switching back to the original mode. On going back to the original mode, the device should function normally as before.
Based on the discussion here till now and from what I have found on my own, there seem to be the following possible ways to achieve this. Please review them and let me know what might be the best alternative and how to achieve it: 1. This is similar to switching to the airplane mode. Can someone guide me on how I may be able to modify the airplane mode so that only certain services are disabled in that mode( for eg: only bluetooth gets disabled). 2. As William suggested, services like bluetooth are enforced through Unix gid (comments in permissions.xml and platform.xml). The gids used for this purpose for bluetooth are "net_bt" and "net_bt_admin". If I have understood William's reply correctly, I would have to find out which devices(in /dev) these gids have access to and modify the permissions of those devices for these groups. Where will I have to put code to do this? As far as the robustness of applications against removal of permissions is concerned, won't they handle it in a similar fashion as they do when bluetooth/wi-fi is switched off by the user? On Jul 9, 2:13 pm, Scytmo <[email protected]> wrote: > Also, I wouldn't expect applications to be robust against the > arbitrary removal of permissions. From the developer perspective, any > permission declared in the AndroidManifest.xml *will* be granted to > the application if the application is installed (this is fundamental > to the Android security model). In many cases, the removal of > permissions from an installed application would result in a > SecurityException being thrown. IMHO, it is very unlikely that > applications would catch this - and this will result in a Force > Close. For permissions that map onto supplementary gids, the error > conditions are likely to be different - but, I think the same > principle applies: don't expect applications to gracefully handle the > resulting errors. > > On Jul 9, 6:02 am, William Enck <[email protected]> wrote: > > > Akhilesh, > > > No such mechanism currently exists in the Android source code. > > > However, if I remember correctly, bluetooth is one of the few > > permissions that are enforced via UNIX gid (see comments in /system/ > > etc/permissions.xml). A while ago, I tracked the INTERNET permission > > down to the "inet" gid, which is enforced by a modification to the > > sockets interface in the Linux kernel. If all you want to do is > > disable bluetooth access for some time period, find where the "net_bt" > > and "net_bt_admin" gids are used to enforce access (e.g., kernel, /dev/ > > *). However, be aware of open file descriptors that may need to be > > revoked. > > > Good luck, > > > -Will > > > On Jul 8, 2009, at 2:19 AM, Akhilesh Gupta wrote: > > > > Hi > > > The documentation mentions that "the permissions required by an > > > application are declared statically in that application, so they can > > > be known up-front at install time and will not change after that." > > > Suppose there is a necessity to enforce a system wide security policy > > > to not allow bluetooth access(for example) to any application for a > > > certain period of time. Is there a way to revoke the permission for > > > bluetooth access from all applications for that period of time? > > > If there is no direct way of doing this, can someone guide me on what > > > I can modify/add in the android source code(or where to look in the > > > source) to add this capability to my android compilation. > > > > Thank You > > > Akhilesh Gupta > > > -- > > William Enck > > PhD Candidate > > Department of Computer Science and Engineering > > The Pennsylvania State University > > [email protected]
