On 16 January 2015 at 11:25, John Johansen <[email protected]> wrote:
> On 01/15/2015 07:39 PM, Seth Arnold wrote: > > On Thu, Jan 15, 2015 at 08:23:22PM +0200, Dmitry Kasatkin wrote: > >> I am running stock Ubuntu 14.10 and there I would like to create a > policy > >> which allows program '/sbin/appd' to access directory '/etc/appd/', but > >> forbid for any other program having profile or not. > >> > >> Is there anyway to specify "default" policy which denies access to > >> /etc/food? > > > > You can achieve something like this using AppArmor with some work: > > http://wiki.apparmor.net/index.php/FullSystemPolicy > > > > The gist is that you'd create a profile suitable for your 'init' process, > > create profiles suitable for "everything else", the other profiles on > your > > system, and a profile for /sbin/appd. > > > This approach comes when look to how Apparmor currently works.. That what I want to avoid creating profiles for everything. > > None of the profiles would have /etc/appd/ permissions except the > > /sbin/appd profile. > > > > Every process on your system would then run confined in a profile; at > > least one profile would probably need to be quite permissive -- nearly > > everything would run under that profile. > > > > I haven't yet tried this for myself; I expect it's a fair amount of work > > to get it just right. > > > yes and no, its currently a pita to load a profile early enough to confine > init because it needs to be loaded in the initrd. Basically you need to > compile the policy and stuff it in the initrd with something to load it. > Its not hard, I've done it but it is not something we have automated tools > to do atm. > > There is the experimental default profile work that allows specifying a > default profile that starts in an unconfined state, and then can be > replaced > into an enforing state. This means you need to trust your init up to the > profile load but that is generally the case because apparmor isn't checking > for inconsistent labeling from on offline attack. > > I think the real problem is currently policy is exclusively specified at > the profile level. This makes it hard to specify a rule that should be > applied globally. > > This is something I was looking - "fallback" / global profile for anything has no profiles... That way I could be possible to limit access to resources system wide. > You can achieve it by sticking some deny rules in the base include and > making > sure all profiles include that except your special profile which will need > to include a version of the base without the deny rules. Easy to do by > moving > abstractions/base to abstraction/base-core, and making abstraction/base > include base-core and also specify the deny rules. > > But it works only for apps having profiles? What about apps without profiles? > However this takes more work than say having the ability to specify some > global rules that will automatically get set on all profiles. > > > There is another alternative to doing this that isn't quite ready yet. > You can use stacking to have a master profile that enforces the denies > and stacks regular policy under it. The exception profile would have > rules to have it not stack. > > You mean work you mention bellow? > > TLDR: doing default policy is currently harder than it should be. > There is work currently being done to address a couple of the pain points. > > Can you please point to source code/commit where it is being addressed? Thanks to all for answers.. - Dmitry
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
