[apparmor] [Merge] lp:~chkpnt/apparmor/patch-ruby into lp:apparmor
Gregor Dschung has proposed merging lp:~chkpnt/apparmor/patch-ruby into
lp:apparmor.
Requested reviews:
AppArmor Developers (apparmor-dev)
For more details, see:
https://code.launchpad.net/~chkpnt/apparmor/patch-ruby/+merge/132723
- the globbing as used in /etc/apparmor.d/abstrations/ruby doesn't work for
ruby 1.9.1
- rubygems need {,32,64} in the path, too
--
https://code.launchpad.net/~chkpnt/apparmor/patch-ruby/+merge/132723
Your team AppArmor Developers is requested to review the proposed merge of
lp:~chkpnt/apparmor/patch-ruby into lp:apparmor.
=== modified file 'profiles/apparmor.d/abstractions/ruby'
--- profiles/apparmor.d/abstractions/ruby 2010-12-20 20:29:10 +
+++ profiles/apparmor.d/abstractions/ruby 2012-11-02 16:27:21 +
@@ -9,17 +9,17 @@
#
# --
- /usr/lib{,32,64}/ruby/1.[89]/ r,
- /usr/lib{,32,64}/ruby/1.[89]/*.rb r,
- /usr/lib{,32,64}/ruby/1.[89]/**/*.rb r,
- /usr/lib{,32,64}/ruby/1.[89]/*-linux/*.so mr,
- /usr/lib{,32,64}/ruby/1.[89]/*-linux/**/*.so mr,
-
- /usr/lib{,32,64}/ruby/site_ruby/1.[89]/ r,
- /usr/lib{,32,64}/ruby/site_ruby/1.[89]/*.rb r,
- /usr/lib{,32,64}/ruby/site_ruby/1.[89]/**/*.rb r,
- /usr/lib{,32,64}/ruby/site_ruby/1.[89]/*-linux/*.so mr,
- /usr/lib{,32,64}/ruby/site_ruby/1.[89]/*-linux/**/*.so mr,
-
- /usr/lib/ruby/gems/1.[89]/ r,
- /usr/lib/ruby/gems/1.[89]/** r,
+ /usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/ r,
+ /usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/*.rb r,
+ /usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/**/*.rb r,
+ /usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/*-linux/*.so mr,
+ /usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/*-linux/**/*.so mr,
+
+ /usr/lib{,32,64}/ruby/site_ruby/1.{[89],[89].[0-9]}/ r,
+ /usr/lib{,32,64}/ruby/site_ruby/1.{[89],[89].[0-9]}/*.rb r,
+ /usr/lib{,32,64}/ruby/site_ruby/1.{[89],[89].[0-9]}/**/*.rb r,
+ /usr/lib{,32,64}/ruby/site_ruby/1.{[89],[89].[0-9]}/*-linux/*.so mr,
+ /usr/lib{,32,64}/ruby/site_ruby/1.{[89],[89].[0-9]}/*-linux/**/*.so mr,
+
+ /usr/lib{,32,64}/ruby/gems/1.{[89],[89].[0-9]}/ r,
+ /usr/lib{,32,64}/ruby/gems/1.{[89],[89].[0-9]}/** r,
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [Merge] lp:~chkpnt/apparmor/patch-ruby into lp:apparmor
Hello,
Am Freitag, 2. November 2012 schrieb Gregor Dschung:
Gregor Dschung has proposed merging lp:~chkpnt/apparmor/patch-ruby
into lp:apparmor.
Requested reviews:
AppArmor Developers (apparmor-dev)
For more details, see:
https://code.launchpad.net/~chkpnt/apparmor/patch-ruby/+merge/132723
- the globbing as used in /etc/apparmor.d/abstrations/ruby doesn't
work for ruby 1.9.1 - rubygems need {,32,64} in the path, too
The proposed rules will fail with 1.10 and 2.x ;-)
Since this is mostly about read permissions, what about relaxing the
rules a bit to make them version-independent and easier readable?
I'd propose to use /usr/lib{,32,64}/ruby/1.[89]*/ or even
/usr/lib{,32,64}/ruby/[1-9].[0-9]*/ to be compatible with future ruby
releases up to 9.x ;-)
Even if you don't want to do that:
+ /usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/*.rb r,
+ /usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/**/*.rb r,
You can merge these two lines to
/usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/**.rb r,
+ /usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/*-linux/*.so mr,
+ /usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/*-linux/**/*.so mr,
Same here, merge to:
/usr/lib{,32,64}/ruby/1.{[89],[89].[0-9]}/*-linux/**.so mr,
+ /usr/lib{,32,64}/ruby/site_ruby/1.{[89],[89].[0-9]}/*.rb r,
+ /usr/lib{,32,64}/ruby/site_ruby/1.{[89],[89].[0-9]}/**/*.rb r,
+ /usr/lib{,32,64}/ruby/site_ruby/1.{[89],[89].[0-9]}/*-linux/*.so
mr,
+ /usr/lib{,32,64}/ruby/site_ruby/1.{[89],[89].[0-9]}/*-linux/**/*.so
mr,
Two more pairs to merge ;-)
Regards,
Christian Boltz
--
Bei mir läuft KDE gar nicht.
Völlig korrekt. Logisch. Aber sinnfrei.
[David Haller in opensuse-de]
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] stacked filesystems status update?
On 11/03/2012 09:16 AM, intrigeri wrote: Hi, John Johansen wrote (16 Apr 2012 20:08:42 GMT) : On 04/16/2012 12:48 PM, intrigeri wrote: Hi, as the maintainer of a Live system that uses aufs, I'm severely hit by the lack of support for stacked filesystems in AppArmor. Steve's comment #41 on LP #131976 [0] suggests an easy workaround. However, John's comment #42 explains that there is still a bug in alias processing, that needs to be fixed before this will work. Was this alias processing bug fixed? If it was not, is it tracked anywhere? Sadly it has not been fixed, despite it being a critical bug it requires some major work to fix, there has been progress on it but it is not done. The work around right now is manually splitting some rules, so that the current alias rules can be applied (see below). https://bugs.launchpad.net/apparmor/+bug/888077 aliases as they are currently implemented aren't applied to regular expressions that would match against the alias root. Eg. alias /home/ - /mnt/rw, /** rw, #rule not correctly aliased /home/** rw # rule is correctly aliased I am trying to get this code rework done for the next release post the up coming 2.8 release. Being a compiler only fix it is possible we can backport this to previous releases. Any news on this front? Its still a work in progress, you should see some parser cleanup, and permission rework patches that are leading towards getting this fixed but are insufficient in and of themselves to fix the issue. I hope that we can get it fixed for the 3.0 release due in the spring -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] UDS wrap-up - Etherpad dump
This is a dump from the various session's etherpads, hopefully I haven't missed
anything
AppArmor LXC development
Features in development
- stacking
* POC in 2-3 weeks for base stacking (ie, not userspace namespaces, have
aa_stack_profile as opposed to change stacking in policy)
* this allows is to both limit the container and have profiles within the
container
- conditional rules
* base conditionals by 13.04
* eg:
fs=procfs proc/foo rw,
label=foo /foo/bar rw,
- mount fixes/improvements
* 'umount /mnt/{**,},' - delegation (parent hands capabilities to the child)
Cleaner way of dealing with things like:
deny /sys/[^f]*/** wklx,
deny /sys/f[^s]*/** wklx,
deny /sys/fs/[^c]*/** wklx,
deny /sys/fs/c[^g]*/** wklx,
deny /sys/fs/cg[^r]*/** wklx,
* should be in 13.04 as part of conditionals work
- extended regex matching and boolean operations
eg. allow /** - /sys/fs/cgr*/** wklx,
- netlink? (to filter uevents) - eg network netlink (create,bind,rw),
- on schedule. will look like regular network rule. First pass, mask off a
family or not. planned for 13.10, maybe sooner
- this will also bring in abstract unix domain socket mediation
- labeling
- bug on declaring variables outside of the preamble (ie, in a .d directory)
Can we have all of the above by 14.04? Yes. Work is planned and in progress
- stacking prototype is almost done
- conditional rules are a bit later (base conditionals in 13.04, others later)
Usernamespaces - 14.04
Work items:
These are already planned and need to be brought forward from quantal bps.
These are assigned to members of the security team and will be
reprioritized/revised for raring
Application Confinement (Content Access Helper)
---
Application isolation ensures that applications can only access the data that
is required to run. Often data needs opportunistic access. Eg, a photo
application needs access to an image file for upload. We should provide a
helper to enable confined applications to access files and other content
selected by the user.
Requirements for first iteration:
- file type specific (eg, photos, contacts, etc) with different handlers
1. files
2. photos (needs design)
3. contacts
- need to be able to handle different backends
- need to be able to handle multiple files of same type
- as toolkit agnostic as possible
Future:
- Legacy applications and file selector: could patch gtk to invoke helper
Other helpers need an api that developers would program to
Code to be written:
- trusted helper daemon
- library for API (getFile, getContact, get...)
Questions:
- saving
- how do you save a contact?
- Is the permission grant temporary, or persistent for the sandbox?
- ie. next time the application is launched, or after a reboot is the
extended access remembered
- Is the grant of new permission local to the task or a sandbox?
- this is irrelavent if each application gets its own sandbox but if the
sandbox can be shared...
Prior art:
- iOS does source review for applications that need access to files out of the
sandbox
- Android has an API, but can access anything on the shared drive and anywhere
in its sandbox
- OS X sandbox: has a trusted helper
- http://plash.beasts.org/powerbox.html works with gtk, changes file selection
to do it
- new Windows 8 has something like a trusted helper
- Some similar design work going on at GNOME:
https://live.gnome.org/GTK%2B/ContentSelection,
http://afaikblog.wordpress.com/2012/05/10/gnome-design-update-part-two/
2 parts:
1. API (needs to be defined). Eg the developer wants to upload a picture, or
access a contact.
- define by list of mimetypes
2. How to integrate this with apparmor
- hard link file into directory where there is access (with cleanup)
- new functionality in apparmor to dynamically update the profile
- object delegation
- transfer file over dbus
- helper itself could provide a socket and the helper could shove data into
the other end
Work items:
[mterry] file selector
[mpt] design for photos selector
[mpt] design for contacts selector
[security] dbus
[security] decide on how to expand the permissions
[security+mterry] design of how to make security desicions
Application Confinement (Gnome-Keyring)
---
= Background =
gnome keyring can store passwords and when offline the storage is encrypted.
when online it is decrypted
previous versions had ACLs to control access to the keyring. patched out
because security consider when everything is running under the user session and
several issues. (spoofing, tricking, X spoffing, opening keyring file
itself,etc, etc).
Default assumption when in the default user session with trusted components,
we don't need the ACLs
Going forward, this assumption changes because of the extras repository. Those
applications will run under a sandbox. Some applications in default install of
Ubuntu
Re: [apparmor] [patch 1/3] parameterize parser tests to support different binaries
On 10/26/2012 10:59 AM, Steve Beattie wrote: This patch replaces the hardcoded path to the in-tree apparmor parser in several of the script based test scripts with the APPARMOR_PARSER environment variable, keeping the hardcoded location as the default. It also adds support for overriding the location of the parser via the same environment variable. The make infrastructure is updated to use this, though uses a different variable (PARSER) to drive it. Thus 'make check PARSER=/some/path/to/an/alternate/apparmor_parser' will run all the parser tests on that binary. This is useful for running the testsuite in an automated post-install environment. (It should be noted that doing so will still build and run the unit test binaries based on the source tree.) Acked-by: John Johansen john.johan...@canonical.com -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [patch 2/3] two fixes to the parsers simple test driver
On 10/26/2012 10:59 AM, Steve Beattie wrote:
This patch fixes two issue with the simple test driver. The first is
that child exec that actually ran the parser was located inside the
eval statement. This meant that if the exec failed for some reason
(like the parser didn't exist), the child wouldn't actually die,
but would pop out of the eval and continue running through the loop
of test profiles (while the parent process does the same). This meant
that if the script ran on the full testsuite with a misconfiguration,
it would explode creating O(n^2) processes, where n is the number of
testcase files -- with over 25k testcases, that's a lot. The fis is to
lift the child exec outside the eval{}, then an exec() failure causes
the child process to die correctly.
The second fix is that several of the testcases were added with the
DESCRIPTION field added in lower case (i.e. #=Description blah blah).
This fix makes the regex that pulls out the description not be
case-sensitive.
---
Acked-by: John Johansen john.johan...@canonical.com
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [patch] aa-decode performance tuning
On 11/01/2012 11:06 AM, Christian Boltz wrote: Hello, here's a patch that speeds up aa-decode - in my case from 1.9s to 0.3s (test log with about 900 lines, with 16 encoded lines) The trick is to use bash regex matching instead of calling egrep for each line. It would probably also be possible to replace the sed calls with bash regex matching, but the savings would be minimal because typically most lines are not encoded. BTW: Not having quotes arond the regex is intentional - with quotes added, bash wouldn't take it as regex. So I am fine with this if we are going to drop more generic shell compat and require bash. I know in the past we have tried to not require bash, but I am unsure how important that is atm === modified file 'utils/aa-decode' --- utils/aa-decode 2012-10-15 22:19:49 + +++ utils/aa-decode 2012-11-01 17:57:33 + @@ -70,7 +70,7 @@ while read line ; do # check if line contains encoded name= or profile= -if echo $line | egrep ' (name|profile)=[0-9a-fA-F]' /dev/null ; then +if [[ $line =~ \ (name|profile)=[0-9a-fA-F] ]]; then # cut the encoded filename/profile name out of the line and decode it ne=`echo $line | sed 's/.* name=\([^ ]*\).*$/\\1/g'` Regards, Christian Boltz -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] RAppArmor video tutorials
On Mon, Nov 5, 2012 at 2:21 PM, John Johansen john.johan...@canonical.comwrote: Interesting, I am slowly working my way through them Great, let me know if you have any comments. thanks for doing them, do you mind if I link to them from the apparmor wiki? Sure, that would be cool. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] UDS wrap-up - audio
And the audio for all UDS sessions http://mirrors.tumbleweed.org.za/uds-r/ -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
