Deny access to file for all applications with apparmor?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Deny access to file for all applications with apparmor?

Boyan Tabakov
Hi,
I was recently going through the manuals of apparmor. As far as I could
understand you can create profiles for specific executables. I was wondering,
however, is it possible to create a 'generic' profile that should be applied
to ANY process started. Or, what I really want to accomplish, how can I deny
access to specific file for ALL processes, except, let's say one or two?
If I understand the concept right, this can't be done, but let me know if I am
wrong, please!

--
Blade hails you...

Toll no bell for me father
But let this suffering pass from me
Send me no shepherd to heal my world
But the Angel - the dream foretold
                         --Nightwish

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Deny access to file for all applications with apparmor?

Carlos E. R.-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The Saturday 2006-09-30 at 11:44 +0300, Boyan Tabakov wrote:

> Or, what I really want to accomplish, how can I deny
> access to specific file for ALL processes, except, let's say one or two?
> If I understand the concept right, this can't be done, but let me know if I am
> wrong, please!

The file could belong to a certain user, and only he could open it. The
processes in question could be run by that user (or be suid to that user).
Perhaps a better alternative would be acl.M S6

- --
Cheers,
       Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFFHv4HtTMYHG2NR9URAsD0AJ9gKO5nSOxbA4iEMBGaCrzlEw4vXwCfaFxT
TFpDa94R7T6Cv1FusJYXQYU=
=imXE
-----END PGP SIGNATURE-----


--
Check the headers for your unsubscription address
For additional commands, e-mail: [hidden email]
Security-related bug reports go to [hidden email], not here

Reply | Threaded
Open this post in threaded view
|

Re: Deny access to file for all applications with apparmor?

Boyan Tabakov
On 1.10.2006 02:30, Carlos E. R. wrote:
> The Saturday 2006-09-30 at 11:44 +0300, Boyan Tabakov wrote:
> > Or, what I really want to accomplish, how can I deny
> > access to specific file for ALL processes, except, let's say one or two?
> > If I understand the concept right, this can't be done, but let me know if
> > I am wrong, please!
>
> The file could belong to a certain user, and only he could open it. The
> processes in question could be run by that user (or be suid to that user).
> Perhaps a better alternative would be acl.M S6

So this is not possible with apparmor? I'll try the way you say. Thanks!

--
Blade hails you...

Never sigh for better world
It's already composed, played and told
Every thought the music I write
Everything a wish for the night
                           --Nightwish

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Deny access to file for all applications with apparmor?

Carlos E. R.-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The Sunday 2006-10-01 at 10:15 +0300, Boyan Tabakov wrote:

> So this is not possible with apparmor? I'll try the way you say. Thanks!

I can't say that, I'm no AA expert. I only say that it should be possible
the other way.

- --
Cheers,
       Carlos E. R.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFFH6zTtTMYHG2NR9URAi1PAJ92xFGBlPk9xn1Fw1Drrh4y3JqDuACcDhht
WoKttAbyGLeT7JT6pW9g0TA=
=+Phv
-----END PGP SIGNATURE-----


--
Check the headers for your unsubscription address
For additional commands, e-mail: [hidden email]
Security-related bug reports go to [hidden email], not here

Reply | Threaded
Open this post in threaded view
|

Re: Deny access to file for all applications with apparmor?

Boyan Tabakov
On 1.10.2006 14:55, Carlos E. R. wrote:
> I can't say that, I'm no AA expert. I only say that it should be possible
> the other way.
OK. I did it the way you said. Works fine now.
Thanks again...
--
Blade hails you...

The sun is sleeping quietly
Once upon a century
                --Nightwish

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Deny access to file for all applications with apparmor?

Boyan Tabakov
In reply to this post by Boyan Tabakov
On 8.10.2006 03:56, Crispin Cowan wrote:

> AppArmor currently does not have a way to do this, but it is in our road
> map. The idea would be a "default profile" that applies to *any* process
> started, which does not otherwise have an explicit profile. The problem
> with the default profile approach is that this profile has to
> simultaneously satisfy 2 requirements:
>
>    1. Be "tight" enough that a process confined only by the default
>       profile cannot corrupt AppArmor itself.
>    2. Be "loose" enough that administrative processes, such as YaST and
>       RPM, can still function.
I see. Hope you will come up with a solution!

>     * The security of the default profile will be exceptionally weak if
>       it is a negative profile. This is for all the usual security
>       weaknesses of a default allow policy.

OK, but how would this 'weakness' be any different than the current state,
where there is no profile assigned at all to most of the processes. If the
default negative profile is empty, that would mean 'access granted' by
default, which won't corrupt anything.

>     * The usability of the system will be severely compromised if the
>       default profile is a positive (normal) profile. *Every* process in
>       the system will be subject to this default profile, and so lots of
>       "normal" UNIX administrative procedures won't work.

A default restrictive profile could render the system completely unusable.
Thats why I guess the default profile should be negative only. If it is
positive, it would truly need a lot time to develop.

> Therefore, using the default profile feature is likely to be appropriate
> only for specialized situations where the configuration can be limited
> to a specific need, and therefore its administrative needs will be
> relatively simple.

Exactly! My situation is like this. But having the tools to do this, only
gives the administrator more options. It means that the administrator should
be paying more attention, too.

Good luck with the project!

--
Blade hails you...

All the same take me away
We're dead to the world
              --Nightwish

attachment0 (196 bytes) Download Attachment