Re: [apparmor] RFC: Patch [Bug 1207424] Re: mod_apparmor should let me use ServerName as default hat name
On Fri, Aug 02, 2013 at 01:41:37AM -0700, John Johansen wrote: > This is a first pass at providing the feature requested in Bug 1207424 > > It leverages the appache config option > > AADefaultHatName > > and when its value is specified as > > > the hostname will be looked up and used. Obviously this patch isn't > complete, but its a first pass and I wanted feedback before I put any > more work into it. Hm, I don't think this is what the intention of the bug was describing. This doesn't want to fall back to the actual host name, it wants AADefaultHatName to contain the virtualhost ServerName. I assume this can really only be implemented at check-time, with a similar "empty" value? I.e. AADefaultHatName should contain the string "" or something, and at check time, "" will be expanded to the servername of the currently active vhost for the request. I haven't read the code at all though, so I'm kind of guessing blindly. :) -Kees -- Kees Cook -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [RFC] handling XDG user directories
On 08/06/2013 12:18 PM, Jamie Strandboge wrote: > On 08/06/2013 01:45 PM, John Johansen wrote: >> On 08/05/2013 03:59 PM, Jamie Strandboge wrote: > >>> and users/admins can adjust /etc/apparmor.d/tunables/xdg-dirs or drop files >>> into >>> /etc/apparmor.d/tunables/xdg-dirs.d, providing a welcome convenience[2]. >>> > ... >> I know that people like the drop in dir bits, but quite bluntly I don't, for >> most >> things, its a way of papering over real problems (of course I consider >> treating >> profiles the way we do with packaging as a problems so ...) > > Well, we have it for home too, so I followed that (and we had the same > conversation when I added it-- the slipperiness of my argument is not lost on > me). We could make all the .d directories distro specific, but Debian derived > distros would most likely all end up implementing .d themselves (we can't fix > their longstanding conffile handling so they'll need to come up with something > at least until policy is moved somewhere else). I am one that agrees that the > .d > directories work well enough with minimal effort (of course, I'm biased) and I > can drop the .d directory and have distros do what they want (Debian and > Ubuntu > will likely have to do .d in the short term (there are other more convoluted > options, but we don't have to discuss them here), but others could simply > append > the output of apparmor-xdg-dirs*.py to /etc/apparmor.d/tunables/xdg-dirs). > > ... > No, this was just me taking the opportunity to rant about conf file handling and policy. For the moment I will accept its the best solution we can offer, and I would rather try to standardize it than having each distro end up with the same solution, with slightly different names -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [RFC] handling XDG user directories
On 08/06/2013 01:45 PM, John Johansen wrote: > On 08/05/2013 03:59 PM, Jamie Strandboge wrote: >> and users/admins can adjust /etc/apparmor.d/tunables/xdg-dirs or drop files >> into >> /etc/apparmor.d/tunables/xdg-dirs.d, providing a welcome convenience[2]. >> ... > I know that people like the drop in dir bits, but quite bluntly I don't, for > most > things, its a way of papering over real problems (of course I consider > treating > profiles the way we do with packaging as a problems so ...) Well, we have it for home too, so I followed that (and we had the same conversation when I added it-- the slipperiness of my argument is not lost on me). We could make all the .d directories distro specific, but Debian derived distros would most likely all end up implementing .d themselves (we can't fix their longstanding conffile handling so they'll need to come up with something at least until policy is moved somewhere else). I am one that agrees that the .d directories work well enough with minimal effort (of course, I'm biased) and I can drop the .d directory and have distros do what they want (Debian and Ubuntu will likely have to do .d in the short term (there are other more convoluted options, but we don't have to discuss them here), but others could simply append the output of apparmor-xdg-dirs*.py to /etc/apparmor.d/tunables/xdg-dirs). ... >> translations for these directories happens outside of the user's control. >> Users >> who modify ~/.config/user-dirs.dirs can update policy like they need to now. >> > err how? I thought the point was to stop the user from being able to directly > modify policy. > > If you mean that a user can set their translations sure, but again that > doesn't > currently reflect what system policy does. The sys admin can choose the set > of local translations that are acceptable to system policy > My statement wasn't clear. Any users who are not admins will have to live with admin system policy or request it be updated. Users who are also admins of their machines can update ~/.config/user-dirs.dirs as desired, but then are expected to update their apparmor system policy. In short, I was trying to say simply that this proposal does not try to solve everything, but is in line with how we currently handle any other policy, tunables or abstractions where the user is trying to do something different than system policy allows. ... >> I did not test other tools (aa-logprof, etc) for these utf-8 strings, but any > oh please don't, I don't want to go there > >> problems there would be just bugs (and my proposal doesn't actually add utf-8 >> strings). >> > well it might be more than that as those strings are subject to python and > perls > string handling Yeah, hence the 'etc' ;) ... >> PS - note that this (intentionally) doesn't cover the XDG base-dir >> specification, though we could solve it in the same manner. Create an >> /etc/apaprmor.d/tunables/xdg-basedir tunable with standard values, then >> create >> the /etc/apparmor.d/tunables/xdg-basedir.d directory that people can use if >> they >> want. I don't think we would provide any more tools beyond to avoid crossing >> an >> privilege boundaries and mucking around in $HOME. >> > yeah, this one will require some careful thought/implementation to ensure we > aren't shooting ourselves in the foot Agreed, but I also think these are far less likely to change and what we currently in our policy do is sufficient for most users and distributions. -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [RFC] handling XDG user directories
On 08/05/2013 03:59 PM, Jamie Strandboge wrote:
> = Background =
>
> The xdg-user-dirs specification[1] allows for translatable and movable common
> directories. While this may be beneficial for users who for example want to
> have
> ~/Pictures translated into their own language, this flexibility provides
> challenges for AppArmor. Untranslated xdg user directories are typically (see
> ~/.config/user-dirs.dirs):
> XDG_DESKTOP_DIR="$HOME/Desktop"
> XDG_DOWNLOAD_DIR="$HOME/Downloads"
> XDG_TEMPLATES_DIR="$HOME/Templates"
> XDG_PUBLICSHARE_DIR="$HOME/Public"
> XDG_DOCUMENTS_DIR="$HOME/Documents"
> XDG_MUSIC_DIR="$HOME/Music"
> XDG_PICTURES_DIR="$HOME/Pictures"
> XDG_VIDEOS_DIR="$HOME/Videos"
>
> On an Ubuntu system with the fr_CA locale installed, these become:
> XDG_DESKTOP_DIR="$HOME/Desktop"
> XDG_DOWNLOAD_DIR="$HOME/Téléchargements"
> XDG_TEMPLATES_DIR="$HOME/Templates"
> XDG_PUBLICSHARE_DIR="$HOME/Public"
> XDG_DOCUMENTS_DIR="$HOME/Documents"
> XDG_MUSIC_DIR="$HOME/Musique"
> XDG_PICTURES_DIR="$HOME/Images"
> XDG_VIDEOS_DIR="$HOME/Vidéos"
>
> While the kernel and AppArmor parser handle these translations fine, the
> profiles do not. I think we can do better and make this a bit easier for
> distributions.
>
I'd like to see how we could make it worse, that would be a feat ;)
> = Proposal =
>
> As an upstream, we can vastly improve the situation by simply creating the
> xdg-dirs tunable using the default 'C' xdg-user-dirs values:
> $ cat /etc/apparmor.d/tunables/xdg-dirs
> @{XDG_DESKTOP_DIR}=Desktop
> @{XDG_DOWNLOAD_DIR}=Downloads
> @{XDG_TEMPLATES_DIR}=Templates
> @{XDG_PUBLICSHARE_DIR}=Public
> @{XDG_DOCUMENTS_DIR}=Documents
> @{XDG_MUSIC_DIR}=Music
> @{XDG_PICTURES_DIR}=Pictures
> @{XDG_VIDEOS_DIR}=Videos
>
> # Also, include files in tunables/home.d for site-specific adjustments to
> # the various XDG directories
> #include
>
> and then create the /etc/apparmor.d/tunables/xdg-dirs.d directory. With that
> alone, we can start using rules like this in our upstream policy:
>
> owner @{HOME}/@{XDG_MUSIC_DIR}/** r,
>
makes sense
> and users/admins can adjust /etc/apparmor.d/tunables/xdg-dirs or drop files
> into
> /etc/apparmor.d/tunables/xdg-dirs.d, providing a welcome convenience[2].
>
hrmmm, this [2] is not good, the @{HOME} variable in the expression
@{XDG_DESKTOP_DIR}=@{HOME}/Desktop
should have expanded, this is a bug we need to look into to.
I know that people like the drop in dir bits, but quite bluntly I don't, for
most
things, its a way of papering over real problems (of course I consider treating
profiles the way we do with packaging as a problems so ...)
> This of course doesn't solve everything. Because users can modify theirrs
> ~/.config/user-dirs.dirs file at will and have it point anywhere, so we can't
> examine those files and do anything automatic there (when we have user policy
> we
> can revisit this). This proposal handles translations well though and use of
This depends on what you are trying to enforce. If its a system level policy
that
is anything but advisory we can't ever let the user control the location.
If its a system level policy enforcing an advisory location for the user
circumsribed
by some larger control eg.
@{HOME/** intersected with user defined @{HOME}/@{XDG_DESKTOP_DIR}
or what ever restriction the system policy author chooses to place on a user
accessing
their own files, then sure we can auto generate with the understanding that the
user can change these locations to other files they can access, again making it
advisory only
of course advisory that requires the user log out so policy gets reloaded or
some
such may stop evil app
As for user defined policy, it makes a lot of sense to auto generate
> translations for these directories happens outside of the user's control.
> Users
> who modify ~/.config/user-dirs.dirs can update policy like they need to now.
>
err how? I thought the point was to stop the user from being able to directly
modify policy.
If you mean that a user can set their translations sure, but again that doesn't
currently reflect what system policy does. The sys admin can choose the set
of local translations that are acceptable to system policy
> I have written two tools that we may want to optionally ship[3]:
of course we will want to ship them at least short term
Longer term I am not sure we don't want to have the parser generate a set of
translations at load time instead of having an external app do it. This would
require a control file for the set of translations to use but would have the
advantages of
- keeping policy based translations up to date, without additional packaging
hooks
- would provide the base for user policy to dynamically adjust to users changing
their ~/.config/user-dirs.dirs
> * apparmor-xdg-dirs-simple.py: this takes a locale as an argument and outputs
>to stdout something suitable for dropping into /etc/apparmor.d/xdg-dirs.d.
>Eg:
>$ ./apparmor-xdg-dirs-simple.py zh_HK
>
[apparmor] handling XDG user directories
Hi,
It is a very good idea, really! For now, if I remember correctly,
installing *ubuntu 12.04 and trying to enforce a default Firefox
profile, which contains:
owner @{HOME}/ r,
owner @{HOME}/Public/ r,
owner @{HOME}/Public/* r,
owner @{HOME}/Download/ r,
owner @{HOME}/Download/* rw,
there is a opportunity, that profile did not work, because if user
is e.g. a Greek, already mentioned folders names are in a greek
language, right (which was set during system installation etc.?)
So user must manually change directories names? I'm asking,
because as we know by default only english language is in use
(for now).
Sorry, that I got into a discussion, but I just found this thread about
XDG and read it, because I remember that I always was wondering whether I
need/should change the name of directories in a default Firefox profile: I
mean english to another. I was curious if default profile will work okay,
if user is a non-english person and directories names are in english.
If I remember correctly, there were some bugs about it: #1061693
and maybe #1065538 (which is a duplicate). Of course, I've mentioned only
one example - Firefox. Sorry one more time. It will be very nice
to solve this "problem".
Good luck! Thanks. Best regards.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] lightdm profile from a apparmor.d/abstractions directory.
Hi Mr Seth, Thank you, for providing me an information, about a guest account protections. Generally, I mean a confirmation, that this account is well protected. Anyway, I was just freaking out about a default 'lightdm-guest-session' profile and that - for me - it seems empty. So I was thinking, that it is insecure. Never mind. If it is about a Firefox and a profile itself: to be honest, I thought there will be a lot of changes in the Firefox profile due to large amount of updates in same browser etc. According to everything mentioned above - I will leave it as is. At least for now... Thanks mr Jamie and Seth. Best regards. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
