1. 14 3月, 2018 1 次提交
    • J
      apparmor: add base infastructure for socket mediation · 56974a6f
      John Johansen 提交于
      version 2 - Force an abi break. Network mediation will only be
                  available in v8 abi complaint policy.
      
      Provide a basic mediation of sockets. This is not a full net mediation
      but just whether a spcific family of socket can be used by an
      application, along with setting up some basic infrastructure for
      network mediation to follow.
      
      the user space rule hav the basic form of
        NETWORK RULE = [ QUALIFIERS ] 'network' [ DOMAIN ]
                       [ TYPE | PROTOCOL ]
      
        DOMAIN = ( 'inet' | 'ax25' | 'ipx' | 'appletalk' | 'netrom' |
                   'bridge' | 'atmpvc' | 'x25' | 'inet6' | 'rose' |
      	     'netbeui' | 'security' | 'key' | 'packet' | 'ash' |
      	     'econet' | 'atmsvc' | 'sna' | 'irda' | 'pppox' |
      	     'wanpipe' | 'bluetooth' | 'netlink' | 'unix' | 'rds' |
      	     'llc' | 'can' | 'tipc' | 'iucv' | 'rxrpc' | 'isdn' |
      	     'phonet' | 'ieee802154' | 'caif' | 'alg' | 'nfc' |
      	     'vsock' | 'mpls' | 'ib' | 'kcm' ) ','
      
        TYPE = ( 'stream' | 'dgram' | 'seqpacket' |  'rdm' | 'raw' |
                 'packet' )
      
        PROTOCOL = ( 'tcp' | 'udp' | 'icmp' )
      
      eg.
        network,
        network inet,
      Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
      Acked-by: NSeth Arnold <seth.arnold@canonical.com>
      56974a6f
  2. 10 2月, 2018 4 次提交
  3. 21 11月, 2017 1 次提交
    • J
      apparmor: fix possible recursive lock warning in __aa_create_ns · feb3c766
      John Johansen 提交于
      Use mutex_lock_nested to provide lockdep the parent child lock ordering of
      the tree.
      
      This fixes the lockdep Warning
      [  305.275177] ============================================
      [  305.275178] WARNING: possible recursive locking detected
      [  305.275179] 4.14.0-rc7+ #320 Not tainted
      [  305.275180] --------------------------------------------
      [  305.275181] apparmor_parser/1339 is trying to acquire lock:
      [  305.275182]  (&ns->lock){+.+.}, at: [<ffffffff970544dd>] __aa_create_ns+0x6d/0x1e0
      [  305.275187]
                     but task is already holding lock:
      [  305.275187]  (&ns->lock){+.+.}, at: [<ffffffff97054b5d>] aa_prepare_ns+0x3d/0xd0
      [  305.275190]
                     other info that might help us debug this:
      [  305.275191]  Possible unsafe locking scenario:
      
      [  305.275192]        CPU0
      [  305.275193]        ----
      [  305.275193]   lock(&ns->lock);
      [  305.275194]   lock(&ns->lock);
      [  305.275195]
                      *** DEADLOCK ***
      
      [  305.275196]  May be due to missing lock nesting notation
      
      [  305.275198] 2 locks held by apparmor_parser/1339:
      [  305.275198]  #0:  (sb_writers#10){.+.+}, at: [<ffffffff96e9c6b7>] vfs_write+0x1a7/0x1d0
      [  305.275202]  #1:  (&ns->lock){+.+.}, at: [<ffffffff97054b5d>] aa_prepare_ns+0x3d/0xd0
      [  305.275205]
                     stack backtrace:
      [  305.275207] CPU: 1 PID: 1339 Comm: apparmor_parser Not tainted 4.14.0-rc7+ #320
      [  305.275208] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 04/01/2014
      [  305.275209] Call Trace:
      [  305.275212]  dump_stack+0x85/0xcb
      [  305.275214]  __lock_acquire+0x141c/0x1460
      [  305.275216]  ? __aa_create_ns+0x6d/0x1e0
      [  305.275218]  ? ___slab_alloc+0x183/0x540
      [  305.275219]  ? ___slab_alloc+0x183/0x540
      [  305.275221]  lock_acquire+0xed/0x1e0
      [  305.275223]  ? lock_acquire+0xed/0x1e0
      [  305.275224]  ? __aa_create_ns+0x6d/0x1e0
      [  305.275227]  __mutex_lock+0x89/0x920
      [  305.275228]  ? __aa_create_ns+0x6d/0x1e0
      [  305.275230]  ? trace_hardirqs_on_caller+0x11f/0x190
      [  305.275231]  ? __aa_create_ns+0x6d/0x1e0
      [  305.275233]  ? __lockdep_init_map+0x57/0x1d0
      [  305.275234]  ? lockdep_init_map+0x9/0x10
      [  305.275236]  ? __rwlock_init+0x32/0x60
      [  305.275238]  mutex_lock_nested+0x1b/0x20
      [  305.275240]  ? mutex_lock_nested+0x1b/0x20
      [  305.275241]  __aa_create_ns+0x6d/0x1e0
      [  305.275243]  aa_prepare_ns+0xc2/0xd0
      [  305.275245]  aa_replace_profiles+0x168/0xf30
      [  305.275247]  ? __might_fault+0x85/0x90
      [  305.275250]  policy_update+0xb9/0x380
      [  305.275252]  profile_load+0x7e/0x90
      [  305.275254]  __vfs_write+0x28/0x150
      [  305.275256]  ? rcu_read_lock_sched_held+0x72/0x80
      [  305.275257]  ? rcu_sync_lockdep_assert+0x2f/0x60
      [  305.275259]  ? __sb_start_write+0xdc/0x1c0
      [  305.275261]  ? vfs_write+0x1a7/0x1d0
      [  305.275262]  vfs_write+0xca/0x1d0
      [  305.275264]  ? trace_hardirqs_on_caller+0x11f/0x190
      [  305.275266]  SyS_write+0x49/0xa0
      [  305.275268]  entry_SYSCALL_64_fastpath+0x23/0xc2
      [  305.275271] RIP: 0033:0x7fa6b22e8c74
      [  305.275272] RSP: 002b:00007ffeaaee6288 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [  305.275273] RAX: ffffffffffffffda RBX: 00007ffeaaee62a4 RCX: 00007fa6b22e8c74
      [  305.275274] RDX: 0000000000000a51 RSI: 00005566a8198c10 RDI: 0000000000000004
      [  305.275275] RBP: 0000000000000a39 R08: 0000000000000a51 R09: 0000000000000000
      [  305.275276] R10: 0000000000000000 R11: 0000000000000246 R12: 00005566a8198c10
      [  305.275277] R13: 0000000000000004 R14: 00005566a72ecb88 R15: 00005566a72ec3a8
      
      Fixes: 73688d1e ("apparmor: refactor prepare_ns() and make usable from different views")
      Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
      feb3c766
  4. 27 10月, 2017 1 次提交
  5. 23 9月, 2017 4 次提交
  6. 11 6月, 2017 3 次提交
  7. 09 6月, 2017 2 次提交
  8. 19 5月, 2017 1 次提交
  9. 09 5月, 2017 1 次提交
    • M
      mm: introduce kv[mz]alloc helpers · a7c3e901
      Michal Hocko 提交于
      Patch series "kvmalloc", v5.
      
      There are many open coded kmalloc with vmalloc fallback instances in the
      tree.  Most of them are not careful enough or simply do not care about
      the underlying semantic of the kmalloc/page allocator which means that
      a) some vmalloc fallbacks are basically unreachable because the kmalloc
      part will keep retrying until it succeeds b) the page allocator can
      invoke a really disruptive steps like the OOM killer to move forward
      which doesn't sound appropriate when we consider that the vmalloc
      fallback is available.
      
      As it can be seen implementing kvmalloc requires quite an intimate
      knowledge if the page allocator and the memory reclaim internals which
      strongly suggests that a helper should be implemented in the memory
      subsystem proper.
      
      Most callers, I could find, have been converted to use the helper
      instead.  This is patch 6.  There are some more relying on __GFP_REPEAT
      in the networking stack which I have converted as well and Eric Dumazet
      was not opposed [2] to convert them as well.
      
      [1] http://lkml.kernel.org/r/20170130094940.13546-1-mhocko@kernel.org
      [2] http://lkml.kernel.org/r/1485273626.16328.301.camel@edumazet-glaptop3.roam.corp.google.com
      
      This patch (of 9):
      
      Using kmalloc with the vmalloc fallback for larger allocations is a
      common pattern in the kernel code.  Yet we do not have any common helper
      for that and so users have invented their own helpers.  Some of them are
      really creative when doing so.  Let's just add kv[mz]alloc and make sure
      it is implemented properly.  This implementation makes sure to not make
      a large memory pressure for > PAGE_SZE requests (__GFP_NORETRY) and also
      to not warn about allocation failures.  This also rules out the OOM
      killer as the vmalloc is a more approapriate fallback than a disruptive
      user visible action.
      
      This patch also changes some existing users and removes helpers which
      are specific for them.  In some cases this is not possible (e.g.
      ext4_kvmalloc, libcfs_kvzalloc) because those seems to be broken and
      require GFP_NO{FS,IO} context which is not vmalloc compatible in general
      (note that the page table allocation is GFP_KERNEL).  Those need to be
      fixed separately.
      
      While we are at it, document that __vmalloc{_node} about unsupported gfp
      mask because there seems to be a lot of confusion out there.
      kvmalloc_node will warn about GFP_KERNEL incompatible (which are not
      superset) flags to catch new abusers.  Existing ones would have to die
      slowly.
      
      [sfr@canb.auug.org.au: f2fs fixup]
        Link: http://lkml.kernel.org/r/20170320163735.332e64b7@canb.auug.org.au
      Link: http://lkml.kernel.org/r/20170306103032.2540-2-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Reviewed-by: Andreas Dilger <adilger@dilger.ca>	[ext4 part]
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7c3e901
  10. 16 1月, 2017 12 次提交
  11. 27 7月, 2016 1 次提交
    • A
      apparmor: fix SECURITY_APPARMOR_HASH_DEFAULT parameter handling · 7616ac70
      Arnd Bergmann 提交于
      The newly added Kconfig option could never work and just causes a build error
      when disabled:
      
      security/apparmor/lsm.c:675:25: error: 'CONFIG_SECURITY_APPARMOR_HASH_DEFAULT' undeclared here (not in a function)
       bool aa_g_hash_policy = CONFIG_SECURITY_APPARMOR_HASH_DEFAULT;
      
      The problem is that the macro undefined in this case, and we need to use the IS_ENABLED()
      helper to turn it into a boolean constant.
      
      Another minor problem with the original patch is that the option is even offered
      in sysfs when SECURITY_APPARMOR_HASH is not enabled, so this also hides the option
      in that case.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 6059f71f ("apparmor: add parameter to control whether policy hashing is used")
      Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      7616ac70
  12. 12 7月, 2016 3 次提交
  13. 15 8月, 2013 5 次提交
  14. 28 4月, 2013 1 次提交