-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've pushed it to a pamcap-enhancements branch and I'll will try to
review it quickly.
Thanks
Andrew
KaiGai Kohei wrote:
> Sorry, any TABs are replaced by MUA.
> I'll send the patch again.
>
>> The attached patch provides several improvement for pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Andrew, I've cc:d you here bc in doing this patch I noticed that your
> 64-bit capabilities patch switched this code from an explicit check
> of cap_t(p->cap_effective) to using __capable(). That means that
> now being glossed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
> Remaining issues:
> - We have to mount securityfs explicitly, or use /etc/fstab.
> It can cause a matter when we want to use this feature on
> very early phase on boot. (like /sbin/init)
I'm not altogether clear how you inten
like CAP_MAC_ADMIN
being #define'd then it won't be able to do things like cap_set_flag()
appropriately.
Cheers
Andrew
KaiGai Kohei wrote:
> Andrew Morgan wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> KaiGai Kohei wrote:
>>> Remai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There is already a pam_cap module in the libcap2 package. Can we merge
this functionality?
Cheers
Andrew
[EMAIL PROTECTED] wrote:
> Quoting KaiGai Kohei ([EMAIL PROTECTED]):
>> Serge E. Hallyn wrote:
>>> The capability bounding set is a set beyond w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
>> There is already a pam_cap module in the libcap2 package. Can we merge
>> this functionality?
>
> I think it is a good idea.
>
> However, this module already have a feature to modify inheritable
> capability set.
> How does it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
> Serge,
>
> Please tell me the meanings of the following condition.
>
>> diff --git a/security/commoncap.c b/security/commoncap.c
>> index 3a95990..cb71bb0 100644
>> --- a/security/commoncap.c
>> +++ b/security/commoncap.c
>> @@
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
> Andrew Morgan wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> KaiGai Kohei wrote:
>>>> +if (!!cap_issubset(*inheritable,
>>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
>> Question:
>>
>> The patch does the semantic equivalent of:
>>
>> -#define cap_clear(c) do { cap_t(c) = 0; } while(0)
>> -#define cap_set_full(c) do { cap_t(c) = ~0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
KaiGai Kohei wrote:
> BTW, could you tell me your intention about pam_cap.c is implemented
> with pam_sm_authenticate() and pam_sm_setcred()?
> I think it can be done with pam_sm_open_session(), and this approach
> enables to reduce the iteration of re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> The problem is that when you run a setuid binary, its pP and pE are
> fully raised. The following patch fixes it for me. Chris, does it fix
> your problem? Andrew, am I again confusing myself and doing something
> unsafe?
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
> In the end we can call it CAP_LATE_FOR_DINNER if that's the only way
> I can move forward. CAP_MAC_OVERRIDE is the obvious partner to
> CAP_DAC_OVERRIDE, so that's still my preference. CAP_SMACK_OVERRIDE
> unnecessarily ties it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I believe it was you who once eloquently observed that, at its heart,
the POSIX (sic) capabilities model was all about providing a mechanism
for overriding the prevailing security policy (be it MAC or DAC or
whatever) in a defined way.
Casey Schaufler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
> diff -uprN -X linux-2.6.24-rc3-mm1-base/Documentation/dontdiff
> linux-2.6.24-rc3-mm1-base/include/linux/capability.h
> linux-2.6.24-rc3-mm1-smack/include/linux/capability.h
> --- linux-2.6.24-rc3-mm1-base/include/linux/cap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Signed-off-by: Andrew G. Morgan <[EMAIL PROTECTED]>
Cheers
Andrew
Casey Schaufler wrote:
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> This patch takes advantage of the increase in capability bits
> to allocate capabilities for Mandatory Access C
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This looks good to me.
[As you anticipated, there is a potential merge issue with Casey's
recent addition of MAC capabilities - which will make CAP_MAC_ADMIN the
highest allocated capability: ie.,
#define CAP_LAST_CAP CAP_MAC_ADMIN
].
Signe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
I still feel a bit uneasy about this. Looking ahead, with filesystem
capabilities, one can simulate this same situation with a setuid
'non-root' program as follows:
[EMAIL PROTECTED] ~]$ cat > test.c
main()
{
printf("sleeping (%u)\n", getp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
This warning is just saying that you might want to reconsider
recompiling your dhclient with a newer libcap - which has native support
for 64-bit capabilities. This is supposed to be informative, and not be
associated with any particular error.
-
i] || pP.cap[i]) {
/* Cannot represent w/ legacy structure */
return -ERANGE;
Thanks
Andrew
Kevin Winchester wrote:
> On November 17, 2007 01:16:58 am Andrew Morgan wrote:
>> Hi,
>>
>> This warning is just saying that you might want to reconsider
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Winchester wrote:
> However, I got around the problem by making the code change manually -
> and my network connection is now working. Looking at the code being
> bypassed:
>
> if (pE.cap[i] || pP.cap[i] || pP.cap[i])
>
> looks somewhat we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ackd.
Cheers
Andrew
Serge E. Hallyn wrote:
>>From 5bff8967f45a35f858b96ca673d9bf98eac53d49 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 11:22:04 -0500
> Subject: [PATCH 1/1] file capabilities: allow s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[kernel/signal.c:check_kill_permission() could probably benefit from
getting more consistently indented!]
I'm not sure I can grok your comment. Did you mean:
/* as per, check_kill_permission(), permit if tasks have same uid */
As to content:
Sign
; This patch should be submitted and discussed together with the changes
> Andrew has for securebits.
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFG08y0QheEq9QabfIRAnUhAKCEHyUko292kULNTkRqQOGki2NohgCdGXvV
bc+bHzBbI6sPimdf4UTAzGY=
=vB0u
-----END PGP SI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> To summarize more clearly, I think that so long as we support
> process trees with a sort of !SECURE_NOROOT support, that
> support should include the ability to use prctl(KEEP_CAPS) the
> way one uses it now.
> When a process
fcaps on inode change (v2)
Signed-off-by: Andrew Morgan <[EMAIL PROTECTED]>
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFGuBZDQheEq9QabfIRAtoVAJ9uOG2q9Za0CJqmH0ueLgUHmRIABACdHW3c
SykZm/puZe5JPpiVPAF2rS8=
=Smnk
-END PGP SIGNATURE-
-
To unsub
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Quoting Chris Wright ([EMAIL PROTECTED]):
>> * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
>>> I guess now that I've written this out, it seems pretty clear
>>> that capget64() and capget64() are the way to go. Any objections?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> Quoting Stephen Smalley ([EMAIL PROTECTED]):
>> On Wed, 2007-10-31 at 18:49 -0500, Serge E. Hallyn wrote:
[..]
>>> Also don't do file-capabilities signaling checks when uids for
>>> the processes don't match, since the standard
s.
>>
>>> But no IBM had to do it.
>> Err, no. It was done by Andrew Morgan back in the dark ages.
>> Why on earth do you think IBM did it?
>
> Posix file capabilities the option to replace SUID bit with something
> more security safe only handing out segments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
[time passes]
I'm a little better up to speed on all the kernel now. I don't feel that
I conceptually object so much to this patch-series any more :-)
I do, however, think the patch needs some work:
1) As previously discussed, fE should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fine with me.
Cheers
Andrew
Serge E. Hallyn wrote:
>>From 88115394044e697ac852f7fb9f30483e87f4f598 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Wed, 11 Jul 2007 10:01:01 -0400
> Subject: [PATCH 1/1] file capabilities:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
>
>> I don't particularly mind, but can you point out any case where
>> it is an advantage to have the one bit for f'E rather than just
>> drop f'E altogether? Instead of having
>
>> f'I=something
>> f'P=something
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This contains a typo:
Serge E. Hallyn wrote:
>>From 588755d9498c87c4e963527ba0f49c11107de354 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Wed, 27 Jun 2007 19:55:27 -0400
> Subject: [PATCH 1/1] file capabilities: get_fil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
>> Does that explain it?
>
> Yes, thanks, but then it still could come in handy to have fE be a full
> bitset, so the application gets some eff caps automatically, while
> others it has to manually set...
[We touched on this a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
>> The only reason for having an fE bitmap is to allow a capability-aware
>> program (you really trust to do its privileged operations carefully) to
>> be lazy and get some of its capabilities raised for free. Perhaps you
>> can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
kfree(dcaps);
> Move this two lines down (rc defaults to 0 in goto above):
> from here-->
+clear_caps:
+ if (rc) {
> to here-->
>
>> Hmm? But if we succeeded we still want to free dcaps if we
>> kmall
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Casey Schaufler wrote:
>> Would there be a difference between that and setting either fI or fP
>> (depending on your intent) to those caps, and setting fE=1 in Andrew's
>> scheme?
>
> Arg, you're making me think. The POSIX group went through this,
> l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
> 1. Exactly Andrew describes. Once userspace switches to a new cap
> format, an older kernel simply won't support them
Mmm. Let me see. I think I prefer this one! :-)
> 2. As Andrew describes, but also encode the version numb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Howells wrote:
> Move the effective capabilities mask from the task struct into the credentials
> record.
>
> Note that the effective capabilities mask in the cred struct shadows that in
> the task_struct because a thread can have its capabiliti
>> This patch therefore removes it.
>
> Actually IIUC Andrew Morgan had plans of making securebits per-process,
> which would make them far more usable.
>
> Now maybe he'd just as soon start with a clean slate... Andrew?
-
39 matches
Mail list logo
