On 11/07/2014 03:30 AM, Lennart Poettering wrote:
> On Fri, 07.11.14 03:18, WaLyong Cho (walyong....@gmail.com) wrote:
>
>> On 11/06/2014 11:54 PM, Lennart Poettering wrote:
>>> On Tue, 04.11.14 17:35, WaLyong Cho (walyong....@samsung.com) wrote:
>>>
>>>> In case of systemd has "_" label and run as root, if a service file
>>>> has "User=" option and the command line file has a special SMACK label
>>>> then systemd will fail to execute the command. Generally, SMACK label
>>>> is ignored for the root. But if a service has a "User=" then systemd
>>>> will call setresuid() in the child process. After then it no more
>>>> root. So it should have some of executable label for the command. To
>>>> set the SMACK64EXEC before the uid is changed introduce new
>>>> SmackLabelExec option.
>>>
>>> Hmm, I am not sure I like the abbreviation of this. Can't we just call
>>> this "SmackLabel="?
>> SmackLabel is already used as socket. Can we use that also here?
>
> Well, sure. I mean, SmackLabel= on a socket unit applies to the socket,
> and SmackLabel= on a service unit applies to the processes forked off,
> that feels quite natural I think. Overloading the field in this way
> appears to be quite appropriate to me in this case.
>
>> By the way, I hope to discuss about the naming of the SMACK options.
>> SmackLabel/SmackLabelIPIn/SmackLabelIPOut are. They are used in socket
>> group. According to SMACK description,
>> SMACK64/SMACK64EXEC/SMACK64MMAP/SMACK64TRANSMUTE/SMACK64IPIN/SMACK64IPOUT are
>> the origin attribute name. I think using origin name is most make sense.
>> If you agree, then in this case, SMACK64EXEC will be.
>
> What precisely is the "SMACK64" label, and in which way does it differ
> from "SMACK64EXEC"? The former is the xattr field on files, the latter
> the "current" procfs file on processes?
>
> What is SMACK64MMAP for? Does any of the other labels apply to
> processes?
Sorry, I missed attaching URL:
http://www.webcitation.org/6AqzohCXq
SMACK64
Used to make access control decisions. In almost all cases
the label given to a new filesystem object will be the label
of the process that created it.
SMACK64EXEC
The Smack label of a process that execs a program file with
this attribute set will run with this attribute's value.
SMACK64MMAP
Don't allow the file to be mmapped by a process whose Smack
label does not allow all of the access permitted to a process
with the label contained in this attribute. This is a very
specific use case for shared libraries.
SMACK64TRANSMUTE
Can only have the value "TRUE". If this attribute is present
on a directory when an object is created in the directory and
the Smack rule (more below) that permitted the write access
to the directory includes the transmute ("t") mode the object
gets the label of the directory instead of the label of the
creating process. If the object being created is a directory
the SMACK64TRANSMUTE attribute is set as well.
Maybe SMACK64MMAP/SMACK64TRANSMUTE wasn't used in systemd. So we don't
need to discuss about SMACK64MMAP/SMACK64TRANSMUTE on here.
I'm not an expert on SMACK, but if I add some explain, we generally
assign three kind of label to filesystem object. We usally call them as
label, execute label and transmute. transmute has only effect on
directory. So we just need to think about label and execute label. Every
filesystem objects have to have a label. That can be some string or be
"_" or "*"...but the execute label is excuted process's attribute label.
That can be "none". If a object has "none" execute label then the object
will be run as caller processes label.
(I think I'd confused. We should use SMACK64 or SmackLabel instead
SMACK64EXEC or SmackLabelExec in here.)
Auke, what do you think?
>
> Naming things is always one of the most difficult problems in computer
> science I guesss...
>
> In general we try to not do unnecessary abbreviations, especially for
> more exotic functionality. It's certainly a good idea to stay close to
> the low-level concepts, but then again dropping components of a
> low-level name doesn't sound too bad to me.
>
>>> ifdeffing the include is unnecessary. YOu can just include it without
>>> ifdef protectionn, there's nothing in it that we need to avoid pullin in.
>>
>> SELINUX/APPARMOR also use #ifdef. But can SMACK use without that?
>
> Well, they import system headers, but smack-util.h is not a system
> header, it's shipped in systemd itself...
>
> Lennart
>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
