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] 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
Re: [apparmor] UDS wrap-up
Hello, Am Samstag, 3. November 2012 schrieb John Johansen: So just a quick wrap-up of what happened at UDS-R. First there are no audio recordings that I know of Can you open a bugreport against UDS, please? That's something that needs to be fixed ;-) That said: It seems to become a tradition that I have to provide the recordings ;-) so I finally created a separate directory for them on my homepage. You can download them at www.cboltz.de/uds/ I managed to capture most sessions related to AppArmor and confinement except the last session which was rescheduled in the last minute. I have the following recordings available: 2012-10-apparmor-lxc-development-1.ogg 2012-10-apparmor-lxc-development-2.ogg 2012-10-application-confinement--content-access-helper--cut.ogg 2012-10-application-confinement--gnome-keyring-1.ogg 2012-10-application-confinement--gnome-keyring-2.ogg 2012-10-application-confinement--online-accounts.ogg (some recordings are split into two parts, see the -1 and -2) This time all recordigns are unedited and include all the noise - but there's less noice compared to the previous UDS, so you can actually understand what was said ;-) Unfortunately someone broke the UDS schedule page http://summit.ubuntu.com/uds-r/track/security/ which means I'm unable to access the pads. John, can you please paste all session notes into a mail and send them to the mailinglist to have them in the list archive? BTW, when speaking about conferences: If you are interested in recordings from the openSUSE conference, http://blip.tv/openSUSEtv and http://www.youtube.com/opensusetv are the places to go. My AppArmor workshop was not recorded (wrong room, you probably wouldn't learn something new from it anyway ;-) but at least I have a photo and the slides on blog.cboltz.de ;-) and I lost access to my home server while there so I didn't end up setting it to record the live stream either. Maybe you are interested in my solution which doesn't require to manually restart the recording after the automatic hourly icecast disconnect: while true ; do wget http://icecast.ubuntu.com:8000/b3-m3.ogg sleep 1 done You'll of course end up with some files you don't need, but it makes sure you have everything you want - even if a session lasts a bit longer than planned ;-) (Disk space is not really an issue - with ~30 MB per hour, you won't fill up your harddisk even if you recode several days without any break.) The general take away is that we will be continuing on the core improvements that we began back in UDS-Q (6 months ago), and we will begin the work towards sandboxing application on the desktop. In particular, we have plans to continue the work on adding apparmor support to dbus, having a trusted file picker that can be run outside of a sandbox, and a gsettings backend that can be used to mediate access to desktop settings. IMHO the filepicker is the most important thing - basically it's the only missing part needed to provide secure and non-annoying[1] profiles for web browsers - and also other desktop applications (but maybe I underestimate on how many places dbus is used nowadays...) Regards, Christian Boltz [1] like you can store downloaded files only in ~/downloads -- vielleicht mal xp draufklatschen (tut weh, muß aber sein..wie bei einer Impfung) und da so ein Analyse Tool wie SiSandra laufen lassen. Beim impfen tötet man die Erreger aber ab, bevor man sie verabreicht... Wie macht man das mit XP? [ Gunnar Salbeck und Manfred Tremmel in suse-linux] -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] UDS
Hello, I just had a short look at the UDS schedule - and basically it looks like the whole security track is about AppArmor ;-) I'm not sure if I have time to listen to the livestreams, therefore let me send some questions and notes in advance: Most important question: will there be audio recordings available for later download? (IIRC this didn't happen in the last years.) Technical: please hand around the microphone (instead of just sitting around it) - otherwise the livestream is not lough enough and, when made louder, comes with lots of background noise. About the Application Confinement (Content Access Helper) session: At the risk of proposing something that you already came up with: ;-) I'd propose to use a standalone binary that can be used by any application (Px'ed or Ux'ed) for file - open and file - save as. This binary should then copy the file to a temporary location (or use a socket?) and hand it over to the calling application. This solution would cover the most interesting[tm] usecases like confining web browsers or acroread. Applications offering file - save (as in: save again, with the same name) might be a bit trickier, and applications allowing to specify a file to open at the commandline (gimp foo.xcf) as well. The problem is to make sure the user is aware that those files will be opened/written - OTOH displaying a confirmation dialog each time would work, but it would also be annoying. There seems to be a xdg-file-dialog according to google, but I can't find it in the openSUSE repos. Nevertheless, it might be a good place where this feature could be implemented. Oh, and if you implement this, please push it upstream for all applications - I'd love to have this feature in openSUSE too ;-) And a final question that is somewhat unrelated: I remember that using etckeeper was discussed at the last(?) UDS. Did this happen in the meantime? If yes, how good does it work? Regards, Christian Boltz -- Linux just isn't user-friendly when it comes to viruses. You have to work to find and run them. It doesn't happen automatically as it does with Windows. The GNU/Linux folks really should improve this glaring discrepancy. [http://os.newsforge.com/article.pl?sid=05/01/25/1430222from=rss] -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
